[ZODB-Dev] undo --> isn't it supposed to update the in-memory objects?
Mike C. Fletcher
mcfletch@rogers.com
Tue, 11 Jun 2002 22:42:35 -0400
I'm trying to get undo functionality working in an app based on the ZODB
from Zope3 (a version checked out and built this evening, but the
problem has appeared in all versions I've tested (for months)).
Basically, my understanding of transactional undo is that all in-memory
objects should be updated to have their attributes equal to those in the
database prior to the undone transaction via the magic of the cache.
That is, calling:
ID = undoInfo[0]['id']
self.database.undo(ID)
get_transaction().commit()
# following tells tables (indexed collections of objects)
# to consider themselves un-initialised and re-register
# themselves with their own indices the next time they
# are asked to access their indices (which occurs on the
# next line)
for item in APPLICATION.GetTables():
item._v_indices_initialised = 0
item.GetIndices()
should completely reset all objects to the state in the FileStorage
prior to the last committed transaction. In my application, however, to
get even objects which are _not_ held as references anywhere in my
application to update (without raising ConflictErrors), I have to add
the following after the above:
self.connection.reset()
self.connection.sync()
self.connection._resetCache()
Well, sometimes life sucks, sometimes it's golden, that allows all
un-referenced objects to regress to their childhood. It's quite doable
to include it in my app, and I'd be a happy camper if that was the end
of the story...
The problem is that objects which are held by a (strong) reference in
the application are _not_ updated as far as I can see. So, for
instance, an object-editing dialogue being open when I do an undo will
cause a ConflictError when I attempt to do the next commit because the
object serial numbers don't match (in contrast, the collection views
work fine, since they don't hold references to particular objects).
I know there are cases I need to deal with (for instance, where the
object isn't in the previous transaction), but I'm more interested in
understanding why the object _doesn't_ update in place when it _is_ in
the previous transaction. After I understand that I can deal with the
cases where I need to shut down the editing dialog because an object has
disappeared.
Thoughts, pointers, etceteras appreciated,
Mike
_______________________________________
Mike C. Fletcher
http://members.rogers.com/mcfletch/