[ Jim Fulton wrote:]
> Jürgen Herrmann wrote:
>> hi all!
>> i'm trying to form a patch that will result in a method
>> being called on each modified object in a transaction (if that method
>> exists of course) right before commit.
>> main sense is to automate/delay (re)cataloging.
>> first i looked at the Transaction class, as there have been heavy
>> modifications to it from zodb 3.2 to 3.4
> Patching is generally a bad idea.
> I suggest creatinga new catalog (by subclassing or adapting an existing
> - queues updates
> - registers a before-commit callback with the TM on the first update
> in a transaction
> - processes the queue in the callback
> I did this recently for with Zope 3's catalog and it worked very well.
> (I happend to use subclassing and would use adaptation if I were to
> do it again.)
thanks for your reply, i already thought about such a solution and
discarded it because it would still be necessary to call a method
on an object to recatalog it. this step (the programmer's responsibility)
i want to eliminate for several reasons.
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).
as i showed in my first post, the callback to modified objects works
as expected, but in the called method i'm not able to acquire the
responsible Catalog for the modified object.
up to what point can i modify objects in a transaction? why doesn't
acquisition on my objects work in Connection::tpc_begin() ???
regards, juergen herrmann
>> XLhost.de - eXperts in Linux hosting <<
Weiherweg 10, 93051 Regensburg, Germany
Fon: +49 (0)700 XLHOSTDE [0700 95467833]
Fax: +49 (0)721 151 463027
ICQ: 27139974 - IRC: [EMAIL PROTECTED]
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org