[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