[ZODB-Dev] Weird errors with Zope 2.7.7

[Tim Peters]

[Tim]
...
>> BTW, I haven't seen a traceback associated with your "shouldn't load
>> state" problems.  Do any exist?  (I understand they may not be logged,
>> I'm wondering if you can see them from the ZMI.  If it _is_
>> unintentional caching, a traceback could be invaluable.)

[Chris Withers]
> I agree.

Did you do the Google exercise I suggested :-)?  What I found when I did it
is that other people with "cannot load state" problems sometimes found the
answer by looking at a traceback in the ZMI, and then just noting which app
code was doing the load.  It wasn't always that easy, but sometimes it
pointed at exactly the app code responsible for holding on to an old object.

> Do you mind if I apply the following patch to the ZODB trunk?
>
> Index: Connection.py
> =================================================================== ---
> Connection.py       (revision 39510) +++ Connection.py       (working
> copy) @@ -725,7 +725,7 @@
>           if self._opened is None:
>               msg = ("Shouldn't load state for %s "
>                      "when the connection is closed" % oid_repr(oid))
> -             self._log.error(msg)
> +             self._log.error(msg,exc_info=True)
>               raise ConnectionStateError(msg)

As Dieter already said (thanks, Dieter!), this change doesn't make sense.  I
understand that you want to see a traceback, but the traceback you want
doesn't exist before the "raise ConnectionStateError(msg)" on the following
line executes.  App code has to log that; it's "too early" here.

>           try:
> @@ -734,7 +734,7 @@
>               raise
>           except:
>               self._log.error("Couldn't load state for %s", oid_repr(oid),
> -                             exc_info=sys.exc_info())
> +                             exc_info=True)
>               raise
>
>       def _setstate(self, obj):
>
> (the second bit should happen anyway ;-) )

This one is fine.  It doesn't make much difference ("True" and
"sys.exc_info()" _mean_ the same thing in this context), but I like the
"True" spelling better too.

Note that if you changed both instances of exc_info=sys.exc_info() in this
module, it could lose the "import sys" near the top too.  Clean code just
gets cleaner & cleaner ;-)

> Once this is done, how does it wend its way into a Zope 2.8 release?

At some point I'll make a new tag from then-current ZODB 3.4 branch and
change Zope's 2.8 branch to use that new tag.  I usually do that only when a
Zope release is looming, or an important ZODB bugfix gets made.

> What other branches / changes.txt files should I merge to?

ZODB/branches/3.4
ZODB/branches/3.5
ZODB/trunk

If possible, the change should be made in 3.4 first, and then merged from
there to the 3.5 branch and trunk.  I wouldn't change NEWS.txt on any of
them for this, since it's purely internal cleanup with (one hopes) no
visible consequence.