couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Non deterministic winner when bulk saving with all_or_nothing:true
Date Fri, 22 May 2009 20:29:36 GMT
On Fri, May 22, 2009 at 4: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
>

Oh, I totally didn't even stop to think that this was the conflict
resolution going on. What are your thoughts on using something like an
md5 of the document body then? I was always intrigued by the
deterministic revisions because it'd make it possible to update
records without contacting the database first, ie, clients have some
knowledge of what should be in the db, then they can just calculate
the id client side without getting the random id.

> 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