Log message for revision 29871: Changed sub-transaction abort code to not invalidate created objects. There's really no point, because created objects will be unreachable after invalidating old objects. Also, if a created object is non-ghostifiable, it will try to load it's state again, and then either it would fail or it would load non-committed state.
Changed: U Zope/branches/jim-fix-zclasses/lib/python/ZODB/Connection.py -=- Modified: Zope/branches/jim-fix-zclasses/lib/python/ZODB/Connection.py =================================================================== --- Zope/branches/jim-fix-zclasses/lib/python/ZODB/Connection.py 2005-04-04 11:04:27 UTC (rev 29870) +++ Zope/branches/jim-fix-zclasses/lib/python/ZODB/Connection.py 2005-04-04 11:04:33 UTC (rev 29871) @@ -705,7 +705,7 @@ self._storage = self._tmp self._tmp = None - # Note: If we invalidate a non-justifiable object (i.e. a + # Note: If we invalidate a non-ghostifiable object (i.e. a # persistent class), the object will immediately reread it's # state. That means that the following call could result in a # call to self.setstate, which, of course, must succeed. In @@ -722,8 +722,12 @@ # It's really not worth the effort to pursue this. self._cache.invalidate(src._index.keys()) - self._invalidate_creating(src._creating) + # Note that we don't bother to invalidate objects created in + # the subtransactions because they are (or should be :) + # unreachable. + + def _invalidate_creating(self, creating=None): """Dissown any objects newly saved in an uncommitted transaction.""" if creating is None: _______________________________________________ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins