couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Carey <paul.p.ca...@gmail.com>
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
resolution.

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

Paul

On Fri, May 22, 2009 at 9:08 PM, Damien Katz <damien@apache.org> 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 <paul.p.carey@gmail.com>
>> 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
>>>
>
>

Mime
View raw message