Figure out how to reconcile cursors, mutations and connections with sorting/filtering

[wincent]

Splitting this one off from #760, and the related question posted on Stack Overflow here.

Originally this was a question about whether cursors should embed information about sort-order or filtering, and elsewhere we've advised that people should "figure out what data you would need to fetch the next page, and then throw all of that into the cursor", but @eapache raised an example where this can lead to an inconsistent update:

you have two views on the same relay-paginated list, sorted by different fields. The same object appears on both lists, but with different cursors. You have a mutation to create an object, with a RANGE_ADD that specifies different behaviours for the two views. The mutation on the server side has to return a single cursor in the response; which of the two cursors does it return, and what does the other view do since it doesn't have a cursor at all?

So it seems clear that if an object appears in a connection with a particular set of variables, and again in another instance of the connection with different variables, that if these variables influence the cursor then the mutation update can only return a single edge and a single cursor, which by definition can only work for one of these connection-variable tuples.

We'll either need to make a recommendation that cursors be independent of connection variables, which may make life harder for schema authors, or provide a way for mutations to provide consistent updates in the scenario described above (multiple connection-variable tuples, multiple edges each with a unique cursor).

[eapache]

cc @dylanahsmith

[eapache]

make a recommendation that cursors be independent of connection variables, which may make life harder for schema authors

For us, specifically, this would lead to enormous cursors; we would end up serializing the entire object into the cursor so that we would be able to use that cursor for any given sort order. I suspect others would have similar problems.

or provide a way for mutations to provide consistent updates in the scenario described above

I was thinking that the cursor result in the mutation should be parameterized in such a way that the client making the mutation can tell the server "these are the parameter-sets for which I want the cursor for this mutation". Does that make sense?

[wincent]

Does that make sense?

Yes it does.

This is important, so I'm going to fold it into #538, which is about overhauling the mutations API and so has substantial overlap. (It will be easier to manage with the various interrelated mutations issues in a single place.)