RE: [Zope] Re: Saving Pipe3 object
Good point; it's the exact same reason why the second version of my Guest Counter product is broken. (Nasty -- I quality-assured the wrong script before sending it off to production ;-).) Is there any way to create objects that are persistent during the lifetime of the Zope process? I just realized that making the "guests" attribute of the GuestCounter class volatile doesn't really make sense, because the object isn't guaranteed to be cached, and the attribute shouldn't be persistent except in memory. I guess I can store the attribute as part of the product instance, but that's too dirty, unless it's the only way. -- Alexander Staubo http://www.mop.no/~alex/ "QED?" said Russell. "It's Latin," said Morgan. "It means, 'So there you bastard'." --Robert Rankin, _Nostramadus Ate My Hamster_
-----Original Message----- From: Phillip J. Eby [mailto:pje@telecommunity.com] Sent: 27. august 1999 04:34 To: zope@zope.org Subject: RE: [Zope] Re: Saving Pipe3 object
At 04:30 AM 8/27/99 +0200, Alexander Staubo wrote:
The underscore prefix should be enough: Your variable can be named _long_R_Pipe and it won't be pickled.
DC uses the _v_ prefix convention for various stuff, possibly meaning "value"... Who knows.
It stands for 'volatile'. In other words, the opposite of 'persistent'. _v_ attributes are not stored as part of an object's persistent state in the database. It's used for things which should only exist while the object is loaded into memory.
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce
For developer-specific issues, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
Alexander Staubo wrote:
Good point; it's the exact same reason why the second version of my Guest Counter product is broken. (Nasty -- I quality-assured the wrong script before sending it off to production ;-).)
Is there any way to create objects that are persistent during the lifetime of the Zope process?
There is a way from C for objects that don't change. Maybe there should be a hook to allow this from Python. Or a hook saying that you don't want an object to be deactivated. Would you want the hook to apply to individual instances, or to classes? Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Jim Fulton wrote:
Alexander Staubo wrote:
Good point; it's the exact same reason why the second version of my Guest Counter product is broken. (Nasty -- I quality-assured the wrong script before sending it off to production ;-).)
Is there any way to create objects that are persistent during the lifetime of the Zope process?
There is a way from C for objects that don't change. Maybe there should be a hook to allow this from Python. Or a hook saying that you don't want an object to be deactivated. Would you want the hook to apply to individual instances, or to classes?
<blue_sky> Hmm, perhaps persistence/caching options should be settable at all points within the object hierarchy, and acquirable. This means that persistence/caching options should be settable on a ZClass, but overridable on a particular instance. </blue_sky> Michael Bernstein.
From a Python point of view, it seems perfectly natural for a class (or ZClass) to have properties like _no_unload and _no_versions, which instances would inherit, but which they could override in the usual way.
----- Original Message ----- From: Michael Bernstein <mbernstein@profitscape.net>
Jim Fulton wrote:
There is a way from C for objects that don't change. Maybe there should be a hook to allow this from Python. Or a hook saying that you don't want an object to be deactivated. Would you want the hook to apply to individual instances, or to classes?
<blue_sky> Hmm, perhaps persistence/caching options should be settable at all points within the object hierarchy, and acquirable. This means that persistence/caching options should be settable on a ZClass, but overridable on a particular instance. </blue_sky>
participants (4)
-
Alexander Staubo -
Evan Simpson -
Jim Fulton -
Michael Bernstein