[ZODB-Dev] BTree set question

[Tim Peters]

[John Belmonte]
> ...
> I think your example is bad design in that the "total assets" value
> should not be implied.  It should be a scalar with conflict
> resolution, which can merge increments and decrements, and will raise
> a conflict value when falling below the floor value.  Any time you
> modify the asset set, you must also adjust the total assets value
> accordingly. Therefore, two transactions deleting different keys from
> the asset set is not a problem, and if total assets becomes too low
> there will be a conflict.  I use this kind of pattern throughout my
> application.

Sorry, this just sounds like begging the question to me:  if you design your
app so that magical resolution of deleting distinct keys is safe, then
magical resolution of deleting distinct keys is safe.

>> 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.

> I don't see how having conservative resolution rules could be unsafe.

Me neither, although I cringe that "conservative" remains undefined by
principle, and has only been approached via exhaustive case enumeration.

> So the question is, is upgrading the "changing an existing key to the
> same value" case to a conflict error going to bring someone's existing
> app to a crawl?

I don't and can't know, but doubt it.  Every change introduces risk of
introducing new bugs, though, so it's also conservative to avoid making any
changes in the absence of real need.  I see that ChrisM explicitly asked for
a use case where "two transactions assign the same new value to a single
key" causes a problem, and I have that question too.  Since it's never been
raised as an issue before, the idea that it's a common problem can't be
sold.  I don't see that it's a problem at all, although I could certainly
construct a contrived use case where "it's a problem".  But when I did just
that for the case of deleting two distinct keys, you wrote that off as bad
app design.  Whatever use case you have in mind for raising ConflictError
when two transactions assign the same new value to an existing key will
likely be written off as bad app design by someone else.  The real question
is "why risk change?".  It's not enough just that I'd be able to remove my
unhappy XXX comment about it then.