couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Carey <>
Subject Re: Non deterministic winner when bulk saving with all_or_nothing:true
Date Fri, 22 May 2009 21:42:11 GMT
Gaming via dummy revisions is an interesting hack. In any case, this
isn't an issue for me, just something I noticed when writing tests.
Although I am keen on the general idea of plugins for conflict

I won't file a bug, but I will add some more notes to the wiki.


On Fri, May 22, 2009 at 9:08 PM, Damien Katz <> wrote:
> I'm not sure this is fixable with the current architecture. The problem are
> the rules used to determine the current winner are:
> Is Not Deleted > has the most edits > highest revid
> To force one document to be a winning conflict on another document would
> require the second rule to be changed or gamed. Gaming, by inserting a bunch
> of dummy revisions would cause you to either grow you revision list or to
> lose earlier revisions, making spurious edits conflict more likely. Changing
> the rules might work, but you have to consider other usage scenarios.
> While it is annoying behavior to have your conflict suddenly be the loser,
> that can always happen in a multi-user situation no matter what the rules
> are. If you try to special case it for one usage scenario, you might
> negatively impact other equally valid usages. I've thought before about have
> a plug-in to determine the conflict "winners", which might be the way to go
> here.
> -Damien
> On May 22, 2009, at 10:46 AM, Paul Davis wrote:
>> Paul,
>> Yeah, definitely file a bug. If you can cook up some JavaScript to
>> show it, that'd be awesome too.
>> Paul
>> PS, I always feel a bit odd addressing emails to myself.
>> On Fri, May 22, 2009 at 5:41 AM, Paul Carey <>
>> wrote:
>>> Hi
>>> I can reproduce the following behaviour on 0.9.
>>> 1. Save a doc with property x:1 (after saving, the revision = 1-r)
>>> 2. Save again with property x:2 (after saving the revision = 2-r)
>>> 3. Save via bulk_docs with all_or_nothing:true, revision:1-r, and x:3
>>> 4. Load the doc. Half the time x = 2, the other half, x = 3.
>>> This seems wrong to me, I believe x should always be 2. Should I file a
>>> bug?
>>> Thanks
>>> Paul

View raw message