Re: [Zope-dev] How is memory shared between Zope threads?
On Fri, 2 Mar 2001 15:33:37 -0500 (EST), "R. David Murray " [EMAIL PROTECTED] wrote: On Fri, 2 Mar 2001, Erik Stephens wrote: Thanks for the response. If I understand you correctly, then as long a thread does not try to modify an out-of-date object, it will not try to re-read the most current version? Is that the expected behaviour? Hmm. Good question. I seem to remember reading about cases where read-only transactions raised conflict errors in certain cases, but I'm not sure. Hopefully someone from DC can chime in with a definitive answer. The object cache only contains up-to-date objects when a transaction starts. ZODB will also raise a ConflictError when loading an object into the cache for reading, if it has been modified since the start of the transaction. 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 )
[Zope-dev] is there a hook for before the transaction is committed
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 McLaughlin BCSwebservices.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 )
Re: [Zope-dev] DB connection pooling
Dieter Maurer wrote: Erik Stephens writes: I've been working on an implementation of connection pooling for the MySQLDA. Basically, Zope connections will be pooled by connection string to reduce the number of unecessary connections to MySQL. Isn't that trivial with Zope (thanks to acquisition)? Just instantiate a single MySQL Database Connection per connect string (sufficiently high above in the site hierarchy). Use it below through acquisition. For security reasons, we don't want the connections at the root folder (or some equivantly high point in the heirarchy). We cannot find a way to disallow a user of an arbitrary role from accessing the connection properties. If I create a separate role and remove all permissions for that role, users of that role can still access the properties, in particular the connection string with user name and password info. Haven't researched if this is a bug or not. Probably would be better to do that before trying to implement a pooling mechanism, eh? Placing the connections where they are acquirable everywhere takes care of one source of redundant/unnecessary connections. There is still the potential for redundant/unnecessary connections from the fact that each thread maintains its own connections. Of course, for speed, you might want each thread to have its own connection. I've only had experience with the MySQL DA. As far as connection pooling is concerned, are the other DA's similar to the MySQL DA in that respect. Thanks, Erik ___ 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 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] ZCatalog hackery
R. David Murray writes: ... The issue is that parts of the database get updated periodically from an external source. That is, the author and book tables get replaced wholesale. But the Book and Author objects are cataloged using ZCatalog, doing a full text index on a combination of fields from the external database and the html chunks. As far as I can see at the moment, this means that every object has to get uncataloged and recataloged, meaning every time the database update happens the zodb inflates considerably, even though very little data has actually changed. Maybe, you can determine whether something relevant changed and call "catalog_object" only in this case. Dieter ___ 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 )
[Zope-dev] Zope Performance - Windows 2000 .. Newbie
I am getting some serious Zope lag time (15-20 seconds) for simple HTML pages when also trying to hit the same port with data requests. The data requests are = 50 records of text data and SQL Server is optimized (meaning the querys dont take that long, just the connection to Zope). We are using port 8080 on Windows 2000 and was wondering if there is some kind of queue or prioritizing of Zope requests? If so, how can I work around this? Thanks in advance! ___ 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 )
[Zope-dev] Apology! (was: [Zope] Problems with DTML-IN patch!!!)
John Morton writes:
On Fri, 2 Mar 2001 20:55:40 +0100 (CET) Dieter Maurer [EMAIL PROTECTED]
wrote:
Chris Withers writes:
John Morton wrote:
It doesn't appear to be defined in DT_In.py in 2.2.5, but it is ment
ion in
it's doc string, and is available in the dtml-in namespace. I never
got
around to tracking down where it was added in.
"DT_InSV.py" (for DTML In Sequence Variables) defines it, if
it is defined (when I recently looked through the sources, it has
not been).
I can't find them in either DT_In.py or DT_InSV.py in 2.2.5, yet they do
actually work fine...
You are right!
"{next,previous}-sequence-start-number" and friends are still there.
Nobody made the stupidity to remove them.
Please (Brian) accept my apology for my quite rude accusation.
I was just not smart enough to understand the ingenious code in
"DT_In" and "DT_InSV".
Let's review the situation:
"DT_In" only defines "next-sequence-start-index".
But what is pushed onto the DTML namespace is in fact
a "DT_InSV.sequence_variables" object.
Its "__getitem__" is used to look up sequence variables.
The "__getitme__" code is quite sophisticated:
If the key is not defined, it splits it at the last
'-' into prefix and suffix (in our case, suffix is "number").
If the class "sequence_variables" has a method whose
name is given by suffix (this is the case for "number"
and many of its friends),
then the corresponding "index" key is looked up and
the method applied to it.
This way, "next-sequence-start-number" and friends come
into existence, without that one easily recognized how
this happens.
Sorry for the false accusations!
Dieter
___
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
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 )
[Zope-dev] namespace binding in pythonscript
Has the problem with the binding of the namespace in pythonscript been fixed in cvs (if so will it be in b2)? It's a pain to having to call my pythonscript methods using xyz(_=_). --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 comm itted
Hi Tim, I'm glad that worked for you. I think _vote() is the right place to do what you want. See my reply to Steve Alexander for my comments on _v_* attributes. John Tim McLaughlin wrote: 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 McLaughlin BCSwebservices.net Director, Technical Group1950 Old Gallows Road tel: (703) 790.8081 x111Suite 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] namespace binding in pythonscript
On Mon, 5 Mar 2001, R. David Murray wrote: Has the problem with the binding of the namespace in pythonscript been fixed in cvs (if so will it be in b2)? It's a pain to having to call my pythonscript methods using xyz(_=_). Hmm. Actually, it's worse than that, since this particular method is getting called via URL, so I *can't* pass it the namespace explicitly. This is breaking my site. Guess I'll have to write a dtml wrapper as a workaround. --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] Class attr hotfix
I noticed that the most recent hotfix completely
denies access to the getClassAttr, setClassAttr and
delClassAttr from DTML. Is this going to be the
behavior for future Zope versions?
Yes - I think that manipulating actual class objects from
DTML is a Bad Thing.
I know this will break code, so it might be prudent to
alert people when the fix is rolled into the next Zope
release.
I would like to argue for deprecating these functions
in favor of making the ZClass act like a dictionary so
that:
ZClass.set('name',value)
ZClass.get('name'[,inherit])
ZClass['name']
could be called securely from scripts. I would be
willing to write the code for this if you think it
would be a good idea.
I'm not sure why you're wanting to do that, so it scares
me :) I think that manipulation of class objects is
beyond the scope of what "DTML scripters" should reasonably
expect to be able to do.
Brian Lloyd[EMAIL PROTECTED]
Software Engineer 540.371.6909
Digital Creations http://www.digicool.com
___
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 )
Re: [Zope-dev] Class attr hotfix
Brian Lloyd wrote:
I noticed that the most recent hotfix completely
denies access to the getClassAttr, setClassAttr and
delClassAttr from DTML. Is this going to be the
behavior for future Zope versions?
Yes - I think that manipulating actual class objects from
DTML is a Bad Thing.
I know this will break code, so it might be prudent to
alert people when the fix is rolled into the next Zope
release.
I would like to argue for deprecating these functions
in favor of making the ZClass act like a dictionary so
that:
ZClass.set('name',value)
ZClass.get('name'[,inherit])
ZClass['name']
could be called securely from scripts. I would be
willing to write the code for this if you think it
would be a good idea.
I'm not sure why you're wanting to do that, so it scares
me :) I think that manipulation of class objects is
beyond the scope of what "DTML scripters" should reasonably
expect to be able to do.
Oh nothing too scary. Mostly I have used it to store a counter to
automatically assign ids to new ZClass instances.
I was really thinking of this as a way to store properties across all
instances of a ZClass. I agree that manipulating objects from DTML is
BAD. My intention was to just store a property value or three.
--
| Casey Duncan
| Kaivo, Inc.
| [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] Class attr hotfix
Casey Duncan wrote: Oh nothing too scary. Mostly I have used it to store a counter to automatically assign ids to new ZClass instances. I was really thinking of this as a way to store properties across all instances of a ZClass. I agree that manipulating objects from DTML is BAD. My intention was to just store a property value or three. You could use webdav propertysheets attached to the ZClass object for this. -- Steve Alexander Software Engineer Cat-Box limited ___ 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 )
