Re: Non deterministic winner when bulk saving with all_or_nothing:true

[Paul Davis <pa...@gmail.com>]

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 <pa...@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
>

Re: Non deterministic winner when bulk saving with all_or_nothing:true

[Paul Davis <pa...@gmail.com>]

On Fri, May 22, 2009 at 4:08 PM, Damien Katz <da...@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 <pa...@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
>>>
>
>

Re: Non deterministic winner when bulk saving with all_or_nothing:true

[Paul Carey <pa...@gmail.com>]

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 <da...@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 <pa...@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
>>>
>
>

Re: Non deterministic winner when bulk saving with all_or_nothing:true

[Damien Katz <da...@apache.org>]

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 <pa...@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
>>

Re: Non deterministic winner when bulk saving with all_or_nothing:true

[Paul Carey <pa...@gmail.com>]

> PS, I always feel a bit odd addressing emails to myself.

heh, glad I'm not the only one :)

I'll file a bug later today.

Paul

On Fri, May 22, 2009 at 3:46 PM, Paul Davis <pa...@gmail.com> 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 <pa...@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
>>
>