[ZODB-Dev] understanding _p_resolveConflict

[Tim Peters]

On:

>     def _p_resolveConflict(self, oldstate, savedstate, newstate):

I'll add that the "mental inspiration" here is the kind of 3-way merge that
source control systems (like CVS) perform:  compute the delta needed to
transform oldstate to savedstate, then apply that delta to newstate.
Whether it even makes sense to *try* that depends entirely on intended
application semantics, though -- and you have to compute a newstate that
satisfies all your app's intended semantics, which only you can know.

For example, suppose you had a "grand total" kind of object.  It starts life
at 12 (oldstate), transaction 1 changes it to 5 (savedstate), and
transaction 2 changes it to 16 (newstate).  Subtracting 7 is how to change
oldstate to savedstate, and applying that delta to newstate yields 16-7 = 9.
That may or may not be "correct", depending entirely on all the details of
what "grand total" means to you.  If you view it as "transaction 1
subtracted 7, transaction 2 added 4, so -7+4 = -3 is the combined effect",
then 12-3 = 9 is indeed "the correct" result.

For a detailed account of the conflict resolution rules ZODB's BTree use,
see:

    http://zope.org/Wikis/ZODB/BTreeConflictResolution

That primarily shows how complicated a _p_resolveConflict() strategy *can*
be.