[ Jim Fulton wrote:]
> Jürgen Herrmann wrote:
>> [ Jim Fulton wrote:]
>>>Jürgen Herrmann wrote:
>>>>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.)
>> hi jim!
>> 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
>> i want to eliminate for several reasons.
> Which are?
i have developed a framework that nicely handles many2many relations,
heavily uml based, python code generation for attribute getter/setters,
code generation for methods (the def only), automatic index creation...
in short, i want to make everything as easy for the programmer (atm only
first i had the code generation framework write out an explicit
self.reindex_object() at the end of each setter, ugly. it also had
the drawback that setting 3 attributes caused the object to reindex
itself 3 times. not the best for performance.
>> 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).
> I would oppose a per-object callback mechanism. OTOH, I would not
> oppose providing enough hooks to allow you to implement such a mechanism
> yourself without patching ZODB. Note however, that such a mechanism might
> not help you anyway, as discussed below.
>> 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.
> That's because objects registered are not acquisition wrapped.
>> up to what point can i modify objects in a transaction? why doesn't
>> acquisition on my objects work in Connection::tpc_begin() ???
> The objects are not acquisition wrapped.
> IMO, ZODB is way too low a level to do what you want to do.
> Note that what you are trying to do would be easier in Zope 3
> because Zope 3 relies far less on wrappers for acquisition.
oh well, unfortunately i began with that project about 8months ago.
that time zope (x)3 was still not recommended to users on the zope
mailinglist, so i went for zope2. anyways, there must be a solution
to that problem.
if zodb is way to low for my approach, where do i get a possibility
to get notified about a imminent transaction commit? and how could
i find out about the modified objects?
another question: would it be possible to wrap the objects to enable
acquisition in my first approach? guess i'd have to know the container
for that, right (which is no problem, because i have one distinct
container folder for each class)? if that works somehow, i'd bug you
further to provide me with that hooks you described above :)
thanks in advance for your replies...
>> 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