Is there a hook for before the transaction is committed for objects which
subclass Persistent? I found __inform_commit__ for a "registered" object,
but I can't seem to get that to work as I thought it did. I also tried
subclassing TM like a DA, but to no avail.
TIA,
Tim
On Mon, 5 Mar 2001 10:56:38 -0500, Tim McLaughlin
[EMAIL PROTECTED] wrote:
Is there a hook for before the transaction is committed for objects which
subclass Persistent?
__getstate__ ?
But why would you want that?
Toby Dickenson
[EMAIL PROTECTED]
I want to be able to raise an event from the property sheets to the product
if a property changes. I'm calling it manage_afterChange. I want it only
to fire once per transaction so that multiple changes are aggregated.
Here's the declaration I have in mind.
manage_afterChange(oldItems,
On Mon, 5 Mar 2001, Tim McLaughlin wrote:
manage_afterChange(oldItems, newItems)
oldItems: dict of id - values before modifications
newItems: dict of new values at end of transaction
This would allow an elegant "reindex" or notification system for objects.
It would also allow for
Hi Tim,
I have two suggestions, I hope one of them helps.
1) Attached is a TM.py file that I wrote based on the one you mention
below. I've tried to make it more obvious and better documented.
2) Don't use this kind of functionality, but rather use sub-transaction
commits.
The first
John D. Heintz wrote:
Hi Tim,
I have two suggestions, I hope one of them helps.
1) Attached is a TM.py file that I wrote based on the one you mention
below. I've tried to make it more obvious and better documented.
2) Don't use this kind of functionality, but rather use
In what respect are the _v_* attribs gonna cause problems. My guestimate
was that they disappeared upon transaction commit/abort. I'm also not sure
as to why I would need subtrans since I'm only messing with properties of
the object. To my knowledge, subtrans are only necessary to conserve
Hi Steve,
ZPatterns is something that is very high on my must investigate list,
but I am not doing Zope development, but rather ZODB based development.
I'm sure that I can still get lots of good ideas though...
My comment below about _v_* attributes is primarily about not using
functionality
