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:[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:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
