[ZODB-Dev] zodb connection question

[Jürgen Herrmann]

[ Jim Fulton wrote:]
> Jürgen Herrmann wrote:
>> [ Jim Fulton wrote:]
>>
>>>Jürgen Herrmann wrote:
>>>
>>>>hi all!
>>>>
>>>>i'm trying to form a patch that will result in a method
>>>>"_before_commit()"
>>>>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
>>>one)
>>>that:
>>>
>>>- 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.)
>>>
>>>Jim
>>
>>
>> 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
>> responsibility)
>> 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
me :)
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.
>
> Jim

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...

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