[Martijn Pieters]
> 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:

    def __getstate__(self):
        return self.value

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 -
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to