> Did the conflict resolution code for BTrees.Length ever work? Because as
> it stands now the code will fail
You haven't seen this fail, you're _deducing_ that it "must" fail, right?
> as it assumes that integers are passed in, instead of state dictionaries:
> def _p_resolveConflict(self, old, s1, s2): return s1 + s2 - old
Don't overlook this other Length method:
That is, when a Length instance is asked for its state, it returns an
integer. Similarly setting its state expects an integer:
def __setstate__(self, v):
self.value = v
If a class defines both __getstate__() and __setstate__(), the state
object needn't be a dictionary and these methods can do what they want.
> As there are no tests for this that I can see (the BTrees tests are
> kinda very dense),
Confirmed: there are no Length tests in ZODB.
> I am not too keen to go touch this,
Good instincts <wink>.
> but I think this should read:
> def _p_resolveConflict(self, old, s1, s2):
> s1['value'] += s2['value'] - old['value']
> return s1
I expect that would blow up (TypeError: unsubscriptable object),
unless you also removed Length's __getstate__ and __setstate__
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -