-----Original Message----- From: kent@tiamat.goathill.org [mailto:kent@tiamat.goathill.org] Sent: Thursday, August 05, 1999 2:43 PM To: zope-dev@zope.org Subject: [Zope-dev] Product variable values
Is it possible to have class variables in a Zope Product which :
1) are not stored in the object database 2) are reliably updated and retained throughout the life of a zope session when called by _bobo_traverse__()
I've written an example Zope Product to investigate these issues and cannot determine a reliable way to achieve the desired results.
'_v_name' values are only *sometimes* retained from one http get (via _bobo_traverse__() )to the next so those are out. I can't determine a pattern to when they are and when they are not. Sometimes, with two almost identical names, one's value is retained while the other's is not.
This is because _v_ objects are stored in the cache with other objects. When the deactivator code comes around to delete some of the objects and toss them in the persistent storage, _v_ objects are simply thrown away. So you are correct, _v_ objects are not guarenteed to live as long as the Zope process or between HTTP requests.
'name' values are *sometimes* retained from one get to the next within a _bobo_traverse__(), and again, I can't identify when or why. However, changes to 'name' variables are stored in the Zope database, so that's also out.
Sounds like you just want 'name' objects that don't subclass Persistence.Persistent. They won't be 'del'ed by the persistence machinery and will go away when the process quits. -Michel
Thanks
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://www.zope.org/mailman/listinfo/zope-dev
(To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce
For non-developer, user-level issues, zope@zope.org, http://www.zope.org/mailman/listinfo/zope )
In zope.dev, michel wrote:
Sounds like you just want 'name' objects that don't subclass Persistence.Persistent. They won't be 'del'ed by the persistence machinery and will go away when the process quits.
No. Actually, the '_v_name' behavior that exists outside of a __bobo_traverse__ call is what I want. I can handle values being occasionally flushed, but the overhead for them being flushed virtually every time is a bit excessive. See my example Test product posting in Zope.misc to see the behavior that I'm talking about. Then substitute the __getitem__ call in place of the __bobo_traverse__ and see the desired behavior wrt _v_name values. I need the __bobo_traverse__, but I also need the normal _v_name value behavior when called by the __bobo_traverse__. How do I get it? Thanks
participants (2)
-
kent@tiamat.goathill.org -
Michel Pelletier