incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marijn Stollenga <>
Subject Re: conflict resolving
Date Sat, 10 Oct 2009 17:42:03 GMT
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,

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.

View raw message