Re: [Zope-dev] is there a hook for before the transaction is committed
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] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] is there a hook for before the transaction is committed
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, 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 validation (ie. raise error if you don't like newItems). Anyway, that's it. I'm halfway there, just can't get a method to be called on my object _just_ before commit. Cheers, Tim ps. I'm not so sure that __getstate__ will do this for me, but that's probably cause I have no idea what __getstate__ does. It just doesn't sound right ;-) -Original Message- From: Toby Dickenson [mailto:[EMAIL PROTECTED]] Sent: Monday, March 05, 2001 12:08 PM To: Tim McLaughlin Cc: '[EMAIL PROTECTED]' Subject: Re: [Zope-dev] is there a hook for before the transaction is committed 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] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] is there a hook for before the transaction is committed
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 validation (ie. raise error if you don't like newItems). Anyway, that's it. I'm halfway there, just can't get a method to be called on my object _just_ before commit. This sounds an awful lot like the way ZPatterns works... --RDM ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] is there a hook for before the transaction is committed
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. John Tim McLaughlin wrote: 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 ___ Tim McLaughlinBCSwebservices.net Director, Technical Group 1950 Old Gallows Road tel: (703) 790.8081 x111 Suite 201 [EMAIL PROTECTED]Vienna, VA 22182 www .bcswebservices. net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ## # # Zope Public License (ZPL) Version 1.0 # - # # Copyright (c) Digital Creations. All rights reserved. # # This license has been certified as Open Source(tm). # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions are # met: # # 1. Redistributions in source code must retain the above copyright #notice, this list of conditions, and the following disclaimer. # # 2. Redistributions in binary form must reproduce the above copyright #notice, this list of conditions, and the following disclaimer in #the documentation and/or other materials provided with the #distribution. # # 3. Digital Creations requests that attribution be given to Zope #in any manner possible. Zope includes a "Powered by Zope" #button that is installed by default. While it is not a license #violation to remove this button, it is requested that the #attribution remain. A significant investment has been put #into Zope, and this effort will continue if the Zope community #continues to grow. This is one way to assure that growth. # # 4. All advertising materials and documentation mentioning #features derived from or use of this software must display #the following acknowledgement: # # "This product includes software developed by Digital Creations # for use in the Z Object Publishing Environment # (http://www.zope.org/)." # #In the event that the product being advertised includes an #intact Zope distribution (with copyright and license included) #then this clause is waived. # # 5. Names associated with Zope or Digital Creations must not be used to #endorse or promote products derived from this software without #prior written permission from Digital Creations. # # 6. Modified redistributions of any form whatsoever must retain #the following acknowledgment: # # "This product includes software developed by Digital Creations # for use in the Z Object Publishing Environment # (http://www.zope.org/)." # #Intact (re-)distributions of any official Zope release do not #require an external acknowledgement. # # 7. Modifications are encouraged but must be packaged separately as #patches to official Zope releases. Distributions that do not #clearly separate the patches from the original work must be clearly #labeled as unofficial distributions. Modifications which do not #carry the name Zope may be packaged in any form, as long as they #conform to all of the clauses above. # # # Disclaimer # # THIS SOFTWARE IS PROVIDED BY DIGITAL CREATIONS ``AS IS'' AND ANY # EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR # PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL DIGITAL CREATIONS OR ITS # CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, # SPECIAL, EXEMPLARY, OR
Re: [Zope-dev] is there a hook for before the transaction is committed
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. """ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] is there a hook for before the transaction is committed
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 resources. Anyway, what you gave me works! Thanks. It seems I need to override the _vote method (since it is only called once and allows exceptions). As to the other stuff, I'm sure you can enlighten me further as to why. I appreciate the help. Cheers. Tim -Original Message- From: John D. Heintz [mailto:[EMAIL PROTECTED]] Sent: Monday, March 05, 2001 12:45 PM To: Tim McLaughlin Cc: '[EMAIL PROTECTED]' Subject: Re: [Zope-dev] is there a hook for before the transaction is committed 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. John Tim McLaughlin wrote: 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 ___ Tim McLaughlinBCSwebservices.net Director, Technical Group 1950 Old Gallows Road tel: (703) 790.8081 x111 Suite 201 [EMAIL PROTECTED]Vienna, VA 22182 www .bcswebservices. net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] is there a hook for before the transaction is committed
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 like Keeper or TM, but rather just taking advantage of _v_* attributes for caching purposes. What I would want from caching, volatile variables is to reset only when the object, or more safely the session, has conflicted and needs to be reset. I wouldn't want to take the performance hit for the cases where I have only successful commits on the same Connection cache of objects. In that case I would needlessly be reseting my volatile cache. In our code we are overriding _p_deactivate() like this: def __p_deactivate__(self): temp = _v_something Persistent.__p_deactive__(self) _v_something We are only doing this for instance vars that are not sensitive to commit/abort cycles. I think that the ideal situation would allow the volative cache to be reset only in the case of a Conflict, i.e. abort() There are two scopes that this can happen at: 1) The _v_* vars that are only local to the Persistent object that they are defined within. This would be a __p_reset__() method or something that is called by the ZODB Connection mechanism. 2) Session wide, i.e. _v_* vars that are dependent on multi-object state but happen to be stored on one of the Persistent objects. This would be handled by Keeper or TM like solutions. Anyway, this is just my current mental state dump. ;-) Thanks, John Steve Alexander wrote: 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. """ -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
