[ZODB-Dev] strange savepoint behavior

[Tim Peters]

[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).