[ZODB-Dev] strange savepoint behavior
Tim Peters
tim at zope.com
Thu Nov 3 09:44:03 EST 2005
[dvd]
> Hi all,
>
> I'm writing a framework on top of ZODB and I'm now investigate on a
> strange savepoint-related behavior (after a savepoint.rollback the
> attributes of a Persistent-derived class disappears)
>
> While investigate i write this code and found another strange behavior
> (maybe correlated?)
>
> ***** CODE *****
>
> from ZODB import FileStorage, DB
> from persistent import Persistent
> from BTrees.OOBTree import OOBTree
> import transaction
>
> dbname = '/tmp/test.db'
> fstorage = FileStorage.FileStorage(dbname)
> db = DB(fstorage)
> conn = db.open()
> root = conn.root()
>
> class Word(Persistent):
> def __init__(self, word, id):
> super(Word, self).__init__()
> self.id = id
> self._word = word
>
> data = root['data'] = OOBTree()
>
> commonWords = []
> count = "0"
> for x in ('hello', 'world', 'how', 'are', 'you'):
> commonWords.append(Word(x, count))
> count = str(int(count) + 1)
>
> sv = transaction.savepoint()
> for word in commonWords:
> sv2 = transaction.savepoint()
> data[word.id] = word
>
> sv.rollback()
>
> print commonWords[1].id
>
> ***** END CODE *****
>
> if i run this snippet, the last line (print ...) raise a POSKeyError
>
> It works nicely if i omit the "sv2 = transaction.savepoint()" line or if
> the Word class is a subclass of object
>
> Have you any idea?
You didn't say which version of ZODB you're using, but I doubt it matters:
I was able to reproduce the POSKeyError in the current ZODB 3.6 branch.
I expect it's an artificial glitch due to never committing anything (i.e.,
an extreme case some part of the code just isn't expecting). If I add
transaction.commit()
right after your
data = root['data'] = OOBTree()
then the POSKeyError goes away, and I get
Traceback (most recent call last):
File "pos_dvd.py", line 34, in ?
print commonWords[1].id
AttributeError: 'Word' object has no attribute 'id'
instead. That makes sense to me: rolling back invalidates the in-memory
Word objects, and they lose all their user-defined attributes then. Since
the object states were never committed (except to savepoints that were
explicitly thrown away), there's no way to get the attributes back.
I'll open a Collector issue about the POSKeyError (extreme case or not, it
shouldn't happen).
More information about the ZODB-Dev
mailing list