conflict resolving

[Marijn Stollenga <m....@gmail.com>]

Thanks for the help guys! I also have another question. In the game I  
am making there probably can be conflicts as a result of race- 
conditions. I am not sure how I will resolve these, but one idea is to  
find the conflicts in couchdb and resolve them with some routine.

What is the best way to find and resolve conflicts? I could make a  
view that shows conflicting documents, which I periodically check and  
then resolve. But I don't really like the fact that there are delays  
in that setup (between conflict creation and finding it using the  
view). Is there a way to hook up a conflict-resolver immediately as a  
conflict gets created?

Marijn

Re: conflict resolving

[Nils Breunese <n....@vpro.nl>]

Brian Candler wrote:

> On Thu, Oct 08, 2009 at 04:34:49PM +0200, Nils Breunese wrote:
>> You should check the HTTP status code when you add data to your  
>> database. If you get back a 409 Conflict then you should perform your  
>> conflict resolving code.
> 
> ... which only works if all your updates go to the same couchdb server
> (i.e. you are not using multi-master replication).

Very true.

Nils.

Re: conflict resolving

[Brian Candler <B....@pobox.com>]

On Thu, Oct 08, 2009 at 04:34:49PM +0200, Nils Breunese wrote:
> You should check the HTTP status code when you add data to your  
> database. If you get back a 409 Conflict then you should perform your  
> conflict resolving code.

... which only works if all your updates go to the same couchdb server
(i.e. you are not using multi-master replication).

Re: conflict resolving

[Nils Breunese <n....@vpro.nl>]

Marijn Stollenga wrote:

> Thanks for the help guys! I also have another question. In the game I  
> am making there probably can be conflicts as a result of race- 
> conditions. I am not sure how I will resolve these, but one idea is to  
> find the conflicts in couchdb and resolve them with some routine.
> 
> What is the best way to find and resolve conflicts? I could make a  
> view that shows conflicting documents, which I periodically check and  
> then resolve. But I don't really like the fact that there are delays  
> in that setup (between conflict creation and finding it using the  
> view). Is there a way to hook up a conflict-resolver immediately as a  
> conflict gets created?

You should check the HTTP status code when you add data to your 
database. If you get back a 409 Conflict then you should perform your 
conflict resolving code.

Nils.

Re: conflict resolving

[Marijn Stollenga <m....@gmail.com>]

Conflict resolving at readtime may give the problem that the conflict  
can be noticed too late, so you don't notice that your character was  
killed until the next time you are hitting someone. I thinking now  
that I should't do conflict-resolving on the database level but at the  
application level. I was also thinking about applying the 'accept  
conflicts as common state of system' idea on the application level,  
but couldn't really figure out what that would look like.

thanks for the thoughts,
Marijn

On 10 okt 2009, at 18:52, Brian Candler wrote:

> On Thu, Oct 08, 2009 at 11:59:14AM -0400, Paul Davis wrote:
>> There's no server side resolution yet. Its been discussed but nothing
>> has been implemented.
>>
>> Off the top of my head, the hardest part would be figuring out the
>> mechanics of triggering the resolver function. Perhaps implementing  
>> it
>> as working over a view would be easiest, but that much coupling makes
>> be a bit queazy.
>
> My view is that resolving should be done at read time.
>
> The easiest way of doing this would be that if there are document  
> conflicts,
> *all* versions of the document are presented to the client when it  
> asks for
> a particular document.  At the moment you get just one version "at  
> random",
> unless you work quite hard to ask explicitly for all the versions.

Re: conflict resolving

[Brian Candler <B....@pobox.com>]

On Thu, Oct 08, 2009 at 11:59:14AM -0400, Paul Davis wrote:
> There's no server side resolution yet. Its been discussed but nothing
> has been implemented.
> 
> Off the top of my head, the hardest part would be figuring out the
> mechanics of triggering the resolver function. Perhaps implementing it
> as working over a view would be easiest, but that much coupling makes
> be a bit queazy.

My view is that resolving should be done at read time.

The easiest way of doing this would be that if there are document conflicts,
*all* versions of the document are presented to the client when it asks for
a particular document.  At the moment you get just one version "at random",
unless you work quite hard to ask explicitly for all the versions.

Re: conflict resolving

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

There's no server side resolution yet. Its been discussed but nothing
has been implemented.

Off the top of my head, the hardest part would be figuring out the
mechanics of triggering the resolver function. Perhaps implementing it
as working over a view would be easiest, but that much coupling makes
be a bit queazy.

Paul

On Mon, Oct 5, 2009 at 12:03 PM, Marijn Stollenga <m....@gmail.com> wrote:
> Thanks for the help guys! I also have another question. In the game I am
> making there probably can be conflicts as a result of race-conditions. I am
> not sure how I will resolve these, but one idea is to find the conflicts in
> couchdb and resolve them with some routine.
>
> What is the best way to find and resolve conflicts? I could make a view that
> shows conflicting documents, which I periodically check and then resolve.
> But I don't really like the fact that there are delays in that setup
> (between conflict creation and finding it using the view). Is there a way to
> hook up a conflict-resolver immediately as a conflict gets created?
>
> Marijn
>