Jeremy Hylton wrote:
transaction end committed. If end is None, it implies that the
revision returned by loadBefore() is the current revision. There is
an assert here, because the _setstate_noncurrent() is only called if
the object is in the invalidated set, which implies that there is a
non-current revision to read.
Is there any way an object could be invalidated without there being a
non-current revision to read?
What are the possible causes of invalidation?
If I had to guess, I'd say it was a bug in loadBefore(). It looks
like the only ways for loadBefore() to return None for end are
- The very first record for the object has a transaction id less than
the tid argument. If so, end_tid is never set. Not sure this is
compatible with the object being in the invalidated set.
Since I'm not using versions, this is where I'd point the finger.
Perhaps the reasoning about invalidated sets and transaction ids is
wrong in the presence of versions.
Well, there are no versions here, so I can't help with that ;-)
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
