Ordering of primary data #473
Conversation
|
I would like to request to consider this for 1.0. |
|
Note that merging this would make supporting sorting non-optional, which is a change from what we currently have. (Right now, the spec says "A server MAY choose to support requests to sort resource collections".) Making sort support mandatory could be a good thing anyway because, right now, a generic client has no way to know whether their sort request was honored. The other solution is to leave sorting optional, but require servers to state whether they support it by making it an extension. I've discussed that problem/possibility more in #460. |
b656461 to
ddbc46f
Compare
|
@ethanresnick, thanks for pointing this out! The intention of this PR was not to make sorting non-optional, but to explicitly define ordering in the response, so I corrected it. |
|
Cool! I think the PR should also specify how the sorts would be applied to the to-many relationships, as that's a little vague. |
ddbc46f to
0a9ddc6
Compare
|
@ethanresnick, thanks again for pointing it out! I actually did not suggest that sorting could possibly apply to relationships, that sentence was only about ordering. Corrected again. |
|
@hhware, After thinking about this more, I don't think sorts should be able to order the to-many relationship linkage at all (at least not for 1.0), but rather only the resources themselves in a collection. This is what the spec currently specifies, and it's probably not worth changing. So ignore my comment about the vagueness. I'd now suggest removing the text and note about to-many linkage objects all together. After that, I'm +1 on this PR! |
|
@ethanresnick, I do not quite understand your point. This PR is not about sorting directive in the request, it is about ordering of objects in the response. If the to-many relationship is stored in the database in ordered form (i.e., it is stored in a separate table with a column |
|
Ahh, ok, I understand now! As far as the ordered relationships go: saying even that the relationship entries could represent an ordered list seems inconsistent with the other places in the spec where we're currently saying that set semantics apply (e.g. when POSTing to or DELETEing from a to-many relationship). I'm tentatively in favor of treating relationships as lists rather than sets, which would allow for repeated entries and for order to matter, but I think that discussion would have to happen in a separate issue or PR, since it's a big change. Meanwhile, while the current (if implicit) set-based definition is implicit, I still think the note about ordering doesn't belong. |
0a9ddc6 to
3a44c1d
Compare
|
@ethanresnick, I agree with you. I will work on addressing ordering of relationships elsewhere. Updated. |
|
Cool. This looks good to me now! |
|
👍 to merge this PR as is. |
…any-relationship-linkage-objects Ordering of primary data
@ethanresnick, a way to sort relationship linkage object arrays is proposed in #431 (comment) |
IMHO, not enough attention is given in the spec to the way of specifying of order of results in the response, especially given that the specification of sorting in the request is quite detailed. I believe it is just assumed that the way to specify order of results is to order elements in the top-level data, but AFAIK it is not mentioned explicitly anywhere. The only reference to ordering I was able to find is in the Recommendations: "because order is significant" . I suggest to mention this explicitly in the base spec.