You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Jens Alfke <je...@couchbase.com> on 2013/10/10 17:52:35 UTC
Documentation of winning-revision algorithm?
Is there any explicit documentation of the algorithm CouchDB uses to pick the default “winning” revision of a document that’s in conflict? The closest I could find was in the documentation’s chapter on conflicts[1], but although it says several times that CouchDB picks a revision as the default one, it never says how it arrives at it.
This isn’t just an implementation detail, because it explains behavior that can seem weird to developers. This came up for me because I got a bug report saying that “deleted documents come back after a pull replication” — the replication pulled in a conflicting branch in which the document wasn’t deleted. The developer filing the bug report knew about conflicts, but their intuition was that since the local deleted revision was “deeper” (higher generation number) than the one pulled in, it would still win and the doc would still be deleted.
Anyway, my understanding (as implemented in TouchDB/Couchbase Lite) is that the winning revision is picked by these rules, in descending order of priority:
1. A live revision wins over a deleted one.
2. Higher generation number [the numeric prefix of the revision ID] wins.
3. Lexicographically-higher revision ID wins.
Amirite? (I arrived at this after a couple of explanations from Damien, but I still might have missed something…)
Anyway, it would be nice to add this to the docs somewhere.
—Jens
[1] http://docs.couchdb.org/en/latest/replication/conflicts.html
Re: Documentation of winning-revision algorithm?
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Oct 10, 2013 at 9:12 PM, Jens Alfke <je...@couchbase.com> wrote:
>
> On Oct 10, 2013, at 9:57 AM, Benoit Chesneau <bchesneau@gmail.com<mailto:
> bchesneau@gmail.com>> wrote:
>
> maybe that helps:
> https://github.com/refuge/rcouch/wiki/Replication-Algorithm
>
> No, thanks; the replicator actually doesn’t care about the
> winning-revision algorithm, because it doesn’t ever need to find a default
> revision or resolve conflicts. It just adds revisions to the tree.
>
> —Jens
>
ok.
Re: Documentation of winning-revision algorithm?
Posted by Dale Harvey <da...@arandomurl.com>.
https://github.com/apache/couchdb/blob/master/src/couchdb/couch_doc.erl#L351
Yup, looking at he implementation its sorting tuples of the form, {true, 2,
'revid'}, which matches what you explained, looks like my pouch
implementation is also the same
https://github.com/daleharvey/pouchdb/blob/master/src/pouch.merge.js#L199
On 10 October 2013 20:12, Jens Alfke <je...@couchbase.com> wrote:
>
> On Oct 10, 2013, at 9:57 AM, Benoit Chesneau <bchesneau@gmail.com<mailto:
> bchesneau@gmail.com>> wrote:
>
> maybe that helps:
> https://github.com/refuge/rcouch/wiki/Replication-Algorithm
>
> No, thanks; the replicator actually doesn’t care about the
> winning-revision algorithm, because it doesn’t ever need to find a default
> revision or resolve conflicts. It just adds revisions to the tree.
>
> —Jens
>
Re: Documentation of winning-revision algorithm?
Posted by Jens Alfke <je...@couchbase.com>.
On Oct 10, 2013, at 9:57 AM, Benoit Chesneau <bc...@gmail.com>> wrote:
maybe that helps:
https://github.com/refuge/rcouch/wiki/Replication-Algorithm
No, thanks; the replicator actually doesn’t care about the winning-revision algorithm, because it doesn’t ever need to find a default revision or resolve conflicts. It just adds revisions to the tree.
—Jens
Re: Documentation of winning-revision algorithm?
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Oct 10, 2013 at 5:52 PM, Jens Alfke <je...@couchbase.com> wrote:
> Is there any explicit documentation of the algorithm CouchDB uses to pick
> the default “winning” revision of a document that’s in conflict? The
> closest I could find was in the documentation’s chapter on conflicts[1],
> but although it says several times that CouchDB picks a revision as the
> default one, it never says how it arrives at it.
>
> This isn’t just an implementation detail, because it explains behavior
> that can seem weird to developers. This came up for me because I got a bug
> report saying that “deleted documents come back after a pull replication” —
> the replication pulled in a conflicting branch in which the document wasn’t
> deleted. The developer filing the bug report knew about conflicts, but
> their intuition was that since the local deleted revision was “deeper”
> (higher generation number) than the one pulled in, it would still win and
> the doc would still be deleted.
>
> Anyway, my understanding (as implemented in TouchDB/Couchbase Lite) is
> that the winning revision is picked by these rules, in descending order of
> priority:
>
> 1. A live revision wins over a deleted one.
> 2. Higher generation number [the numeric prefix of the revision ID] wins.
> 3. Lexicographically-higher revision ID wins.
>
> Amirite? (I arrived at this after a couple of explanations from Damien,
> but I still might have missed something…)
> Anyway, it would be nice to add this to the docs somewhere.
>
> —Jens
>
> [1] http://docs.couchdb.org/en/latest/replication/conflicts.html
maybe that helps:
https://github.com/refuge/rcouch/wiki/Replication-Algorithm
Re: Documentation of winning-revision algorithm?
Posted by Jens Alfke <je...@couchbase.com>.
On Oct 10, 2013, at 9:14 AM, Jason Smith <jh...@apache.org> wrote:
> Hi, Jens. Well, I was going to link you to my investigation in Gist;
> however it looks like you have already seen it.
I swear I haven’t seen that gist before; someone must’ve hacked into my Github account and posted that comment last month! (It can’t be that my memory is going…)
Anyway, the live-vs-deleted revision rule isn’t mentioned in that gist. As you’re certainly better at reading Erlang than I am, it’d be great if you could look for the evidence in the source sometime :)
—Jens
Re: Documentation of winning-revision algorithm?
Posted by Jason Smith <jh...@apache.org>.
Hi, Jens. Well, I was going to link you to my investigation in Gist;
however it looks like you have already seen it.
https://gist.github.com/jhs/1577159
On Thu, Oct 10, 2013 at 10:52 AM, Jens Alfke <je...@couchbase.com> wrote:
> Is there any explicit documentation of the algorithm CouchDB uses to pick the default “winning” revision of a document that’s in conflict? The closest I could find was in the documentation’s chapter on conflicts[1], but although it says several times that CouchDB picks a revision as the default one, it never says how it arrives at it.
>
> This isn’t just an implementation detail, because it explains behavior that can seem weird to developers. This came up for me because I got a bug report saying that “deleted documents come back after a pull replication” — the replication pulled in a conflicting branch in which the document wasn’t deleted. The developer filing the bug report knew about conflicts, but their intuition was that since the local deleted revision was “deeper” (higher generation number) than the one pulled in, it would still win and the doc would still be deleted.
>
> Anyway, my understanding (as implemented in TouchDB/Couchbase Lite) is that the winning revision is picked by these rules, in descending order of priority:
>
> 1. A live revision wins over a deleted one.
> 2. Higher generation number [the numeric prefix of the revision ID] wins.
> 3. Lexicographically-higher revision ID wins.
>
> Amirite? (I arrived at this after a couple of explanations from Damien, but I still might have missed something…)
> Anyway, it would be nice to add this to the docs somewhere.
>
> —Jens
>
> [1] http://docs.couchdb.org/en/latest/replication/conflicts.html