[ZODB-Dev] BTree set question

[Tim Peters]

[John Belmonte]
> Thanks very much, I'm glad I asked.  While the merge rules are as I
> hoped in the case of a set, I'm alarmed by the mapping value
> modification rule.  It's *not* conservative, and inconsistent (as you
> point out) with key insertion/deletion-- I consider it a bug.

On what basis?  The current rules seem nearly arbitrary to me:  I can
conceive of apps where they do a wrong thing, but for most apps I've
considered, several cases where ConflictError is raised now would work fine
if "the obvious" resolution were performed instead.

A pertinent example of the latter is the case you brought up:  two
transactions add the same key to the same set.  In what objective semantic
sense is that "a conflict"?  Viewed as a mathemetical object, both
transactions leave the set with the same value, and *on its own* that can't
hurt.  It's possible that whenever a transaction adds a key to this set, in
the same transaction it also performs other mutations related to that, and
which aren't idempotent (== not harmless to do *those* twice).  The current
implementation appears to be guarding against that case.  I don't know
why -- or why not.

OTOH, it's not guarding against possible bad consequences of two
transactions deleting different keys from the same set.  For example, maybe
it's a set of assets, and a "liquidate some assets to raise some cash"
process tries to liquidate the smallest subset of assets just sufficient to
raise a specific amount of cash, but subject to a global invariant that the
total value of assets remaining must not fall below some fixed floor value.
Then two concurrent transactions of this kind could easily liquidate
different subsets of assets, and maintain the minimum value on their own,
but end up falling below the floor when they're combined "by magic" via
conflict resolution:  deleting different keys isn't *necessarily* safe.
Neither is adding distinct keys.

In short, any fixed collection of BTree conflict resolution rules is going
to be unsafe and/or needlessly inefficient for some applications.  I can't
find an "organizing principle" consistent with all the choices currently
made, so it's hard to explain (short of exhaustive enumeration) -- but since
apps have relied on these undocumented behaviors for years, any change is
dangerous.  Making conflict resolution strategies pluggable remains
possible.