[ZODB-Dev] zodb connection question

[Jürgen Herrmann]

[ Tim Peters wrote:]
> [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.
hmm, as it seemed quite impossible the way i wanted it, i almost dropped
it from my wishlist. now you say, it's doable...
i already had hacked into zodb.connection, the problem was that the
objects maintained there (self._registered_objects) are not wrapped
for acquisition, thus my reindexing method did not find the catalog to
register with. how would you solve this problem?

to answer your question above: a point-in-time list would be enough for
me, just like to reindex all modified "model" objects. that should only
change indexes.

regards, juergen herrmann
_______________________________________________________________________

>> XLhost.de - eXperts in Linux hosting <<

Juergen Herrmann
Weiherweg 10, 93051 Regensburg, Germany
Fon:  +49 (0)700 XLHOSTDE [0700 95467833]
Fax:  +49 (0)721 151 463027

ICQ:  27139974  -  IRC: #XLhost at quakenet
WEB:  http://www.XLhost.de