Jürgen Herrmann wrote:
[ 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
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
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.

If you are generating code, there there should be no problem
generating the calls to reindex, or, with Zope 2.8, you can use the
Zope 3 event system. which should be cleaner.

You can avoid the cost of indexing on each modification by creating a catalog
with the queuing strategy I describer earlier.


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?

You use events.  Have your generated code generate events, which include
the content-wrapped objects, when an object is modified.  Create an object,
such as a specialized catalog or some other object that maintains a modified-
object collection.  This object tracks which objects have been modified,
collapsing modification events for the same object.  For the sake of discussion,
call this object the "modification buffer".  Provide a subscriber for 
events that registers objects with the modification buffer.  When the buffer
gets the first object (in a transaction), it registers itself to be called by 
transaction machinery. When it is called, it processes (e.g. catalogs) the
objects in its buffer  and clears the buffer.

another question: would it be possible to wrap the objects to enable
acquisition in my first approach?



Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org
For more information about ZODB, see the ZODB Wiki:

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

Reply via email to