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.
