[Zope3-dev] undo --> isn't it supposed to update the in-memory objects?

[Mike C. Fletcher]

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/