[
https://issues.apache.org/jira/browse/COUCHDB-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15723562#comment-15723562
]
Paul Joseph Davis commented on COUCHDB-3239:
--------------------------------------------
[~wilhol] Is this something you're finding is affecting things or its just
different than you expected? The sort that I added for the latest=true fix
specifically makes the assertion that ordering is undefined and revisions may
be returned in any order (but is actually somewhat stable due to the
implementation). Theoretically there aren't any bits of code that rely on the
ordering but its possible I missed something when I did my review for that bug.
Though as a counter case to your proposal, what would you expect the ordering
to be if you specified [1-a], or [1-a,2-b1], or [2-b1,2-b2,3-c1]?
Also, the way that the tree merging works in the fabric coordinator, we'd
actually have to specify the ordering based on the partial revision tree that's
build. If we re-use the ordering defined by `couch_doc:to_doc_info/1` that
would prefer deeper undeleted/not-missing revisions over shallower revisions.
However, its technically any different than what we return now. Its an
arbitrary order based on the results that were obtained given the data we had.
Also, it occurs to me that part of the issue is complexity around revision
trees when inconsistent. For instance, you've proposed having a complete tree
available (which happens on a single node every time), however, in a cluster
one node may be missing the 4-d1 branch and a different node may be missing the
3-c2 branch. When we reconstitute the partial tree in the fabric coordinator
our sense of order would be difficult to retain. And any sufficiently specified
ordering based on input would be complex enough in practice I'm not sure how
much use it would have (ie, in my counter cases where multiple input revs
result in a single returned rev).
> incorrect ordering of results when using open_revs and latest=true
> ------------------------------------------------------------------
>
> Key: COUCHDB-3239
> URL: https://issues.apache.org/jira/browse/COUCHDB-3239
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
> Affects Versions: 2.0.0
> Reporter: Will Holley
> Attachments: docs.json
>
>
> When fetching open_revs with latest=true for a conflicted document, the order
> of results is incorrect. For example, if I create a document with the rev
> tree:
> {code}
> 4-d1
> /
> 3-c1
> /
> 2-b1
> /
> 1-a
> \
> 2-b2
> \
> 3-c2
> {code}
> and ask for {{open_revs=["2-b1","2-b2"]&latest=true}}, the response will
> return {{3-c2}} followed by {{4-d1}} - the reverse of what I'd expect.
> Below is a test/reproduction executed against Couch 1.6.1 and 2.0.
> 1.6.1:
> {code}
> $ export COUCH_HOST="http://127.0.0.1:5984";
> $ curl -XPUT "$COUCH_HOST/open_revs_test"
> {"ok":true}
> $ curl "$COUCH_HOST/open_revs_test/_bulk_docs" -H
> "Content-Type:application/json" -XPOST -d @docs.json
> []
> # GET open_revs=["2-b1","2-b2"]
> $ curl -H "Accept:application/json"
> "$COUCH_HOST/open_revs_test/mydoc?open_revs=%5B%222-b1%22%2C%222-b2%22%5D"
> [{"ok":{"_id":"mydoc","_rev":"2-b1","value":"x-winning"}},{"ok":{"_id":"mydoc","_rev":"2-b2","value":"x-losing"}}]
> # GET open_revs=["2-b1","2-b2"]&latest=true
> $ curl -H "Accept:application/json"
> "$COUCH_HOST/open_revs_test/mydoc?open_revs=%5B%222-b1%22%2C%222-b2%22%5D&latest=true"
> [{"ok":{"_id":"mydoc","_rev":"4-d1","value":"z-winning"}},{"ok":{"_id":"mydoc","_rev":"3-c2","value":"y-losing"}}]
> {code}
> 2.0:
> {code}
> $ export COUCH_HOST="http://127.0.0.1:15984";
> $ curl -XPUT "$COUCH_HOST/open_revs_test"
> {"ok":true}
> $ curl "$COUCH_HOST/open_revs_test/_bulk_docs" -H
> "Content-Type:application/json" -XPOST -d @docs.json
> []
> # GET open_revs=["2-b1","2-b2"]
> $ curl -H "Accept:application/json"
> "$COUCH_HOST/open_revs_test/mydoc?open_revs=%5B%222-b1%22%2C%222-b2%22%5D"
> [{"ok":{"_id":"mydoc","_rev":"2-b1","value":"x-winning"}},{"ok":{"_id":"mydoc","_rev":"2-b2","value":"x-losing"}}]
> # GET open_revs=["2-b1","2-b2"]&latest=true
> $ curl -H "Accept:application/json"
> "$COUCH_HOST/open_revs_test/mydoc?open_revs=%5B%222-b1%22%2C%222-b2%22%5D&latest=true"
> [{"ok":{"_id":"mydoc","_rev":"3-c2","value":"y-losing"}},{"ok":{"_id":"mydoc","_rev":"4-d1","value":"z-winning"}}]
> {code}
> Note the reversed order of the results in 2.0 when {{latest=true}} is
> specified.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
