[ZODB-Dev] savepoint bug

[Edward Moy]

I'm still using a version of ZODB that was top of tree several months 
ago, which has the savepoint/rollback changes I posted.

In using it, I've found a bug that has a strange, non-local behavior 
that is way beyond my understanding of ZODB.  Here is a snippet of the 
code that reproduces the bug:

         self.assertEqual(obj._a, False)
         self.assertEqual(obj._b, False)
         #obj._b = obj._b					#XXX
         rb6 = get_transaction().savepoint()
         obj._b = True
         self.assertEqual(obj._a, False)
         self.assertEqual(obj._b, True)
         rb7 = get_transaction().savepoint()
         obj._a = True
         obj._b = False
         self.assertEqual(obj._a, True)
         self.assertEqual(obj._b, False)
         rb8 = get_transaction().savepoint()	#YYY
         rb8.rollback()						#YYY
         self.assertEqual(obj._a, True)
         self.assertEqual(obj._b, False)
         rb7.rollback()
         self.assertEqual(obj._a, False)
         self.assertEqual(obj._b, True)
         rb6.rollback()
         self.assertEqual(obj._a, False)
         self.assertEqual(obj._b, False)		# <-- error

obj is a persistent object, with two attributes both initially set to 
False.  After the savepoints and rollbacks, both attributes should be 
restored to their original value, but obj._b is True in the last test.

What is strange is that commenting out the lines marked with #YYY, 
results in no error.  Or, with the #YYY lines in, uncommenting the #XXX 
line will also run without error.

I've replaced the persistent object with a 
persistent.list.PersistentList, and used indices 0 and 1 for _a and _b, 
and the exact same behavior results.

Anyone have any ideas?  I've had to put in workarounds in my code like 
#XXX above, but it is ugly and mysterious.

Edward Moy
emoy at apple.com
---------------------------------------------------------------
(This messages is from me as a reader of this list, and not a statement 
from Apple.)