[Zope-dev] is there a hook for before the transaction is committed

[Steve Alexander]

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 sub-transaction 
> commits.
> 
> The first suggestion has more overhead than what I assume you would 
> need, but the second one won't work for all situations.
> 
> A Fishbowl proposal of mine, HashingSupport, was going to use the same 
> kind of hook you are asking about.  In this case though, using 
> sub-transaction commits made a lot more sense.
> 
> In general though, I think that _v_* attributes pose a non-trivial 
> problem that probably requires a hook on abort() if not commit() as well.


Take a look at ZPatterns; specifically, the classes Keeper and Kept from 
ZPatterns/Transactions.py

You can see examples of how they are used in DataSkins.py and Rack.py, 
although there really isn't much to it.

I've included the docstrings below.

class Keeper:
"""Resets an object's per-transaction cache attributes at txn boundaries
    Note that Keepers are created by Kept objects semi-automatically, 
and   there is usually no need to create one manually.  A Keeper
    automatically registers itself with the Zope transaction upon
    creation, and instructs its Kept client to clear its per-transaction
    cache at all transaction boundaries.  Keeper methods are called only
    by the Zope transaction, so don't mess with them."""


class Kept(Base):
     """Thing which has a Keeper to clear its per-transaction cache.

     Objects derived from Kept should reference the 'self._v_Keeper'
     attribute whenever they need to flag that they have made changes to
     their cache that would require it to be cleared.  (Note that
     '_v_Keeper' is an *attribute*, not a method, and so should not be
     called, just referenced.)

     Once this has been done, the next transaction state transition
     that occurs (sub/main transaction commit or abort) will cause
     the object's Keeper to call for a cache reset.

     Subclasses of Kept should define a '__per_transaction_cache_attrs__'
     attribute as a sequence of attributes which they would like to have
     deleted from their '__dict__' at reset time.
     """