[Zope-Coders] FYI: 2.6 a1 today
Shane Hathaway
shane@zope.com
Fri, 14 Jun 2002 16:03:39 -0400
Jeremy Hylton wrote:
>>>>>>"BL" == Brian Lloyd <brian@zope.com> writes:
>>>>>
>
> BL> Hi all - I think we're finally ready to make a 2.6 a1 today. If
> BL> you are working on anything that absolutely needs to go in,
> BL> please let me know ASAP. Otherwise, please hold off on any HEAD
> BL> checkins until tomorrow.
>
> I just noticed a batch of failures in OFS.tests.testRanges, which are
> apparently caused by my change to ZODB/Connection.py this morning. It
> would appear that code in OFS.Image is setting an object's _p_jar but
> not giving it an oid.
>
> Shane mentioned that he found several cases where this occurred as a
> result of bugs in the code. I don't know if that's the case here or
> not. It would be possible to get the tests running again by removing
> (commenting out) some asserts in Connection.register(). It's also
> possible we should try to debug OFS.Image.
>
> Let me know what you'd like to do.
>
> Jeremy
>
> BTW, it looks like there are a bunch of BTrees failures, too.
If you just remove the _p_oid assertion in Connection.register() (line
490, I think), all the tests, including the BTrees tests, pass again.
But I wonder if that causes None to get passed to invalidate() like we
were seeing before. I thought removing the _p_oid assertion in register
would cause some other assertion in Connection to fail, but it didn't.
Can you make sense of that?
To clarify: I saw several places in the code that were setting _p_jar in
a way that might, down the road, lead to bugs. I didn't find any
current bugs. :-) Primarily, containers assumed that they could assign
the _p_jar of new children based on the container's _p_jar, but in
reality, sometimes the container doesn't have its _p_jar set yet either.
Shane