[Jürgen Herrmann]
> so, what i need is a way to have my mechanism called before transaction
> commits (would be possible to use the hooks provided by zodb 3.4 for
> that, sure) and cycle through all modified objects (that's where the
> hooks in 3.4 are not enough for me, they don't provide any way to access
> a list of modified objects).

Note that this isn't just a matter of exposing something to you:  ZODB 3.4
has no list of modified objects, not even internally.  Data managers (like
ZODB.Connection) register with transactions in 3.3+, and data managers are
responsible for keeping track of their own modified objects.  Any number of
data managers may register with a transaction, and each keeps track of its
own details.

So doing what you want would require at least two changes:

1. Adding a new method to the IDataManager interface, to deliver some
   notion of modified objects under the control of the data manager.
   Of course data managers would need to grow implementations of that too.
   Since you're presumably going to be changing even more objects based on
   the stream of modified objects returned, this can be tricky (do you
   get a point-in-time list, ignoring further changes?  or an iterator
   that includes later changes?  if the latter, is it OK to see an object
   more than once in the stream?  like that).

2. Adding a related new method to ITransaction, to combine the notions of
   modified objects from all registered data managers.

That's all doable, but it's hard to see it taking priority over other work.

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to