[ZODB-Dev] zodb connection question

[Jim Fulton]

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

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 modification
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 the
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?

No.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org