Dieter Maurer wrote:
Jim Fulton wrote at 2006-10-6 15:08 -0400:
...
You could implement your sticky attribute at the application level:
def _p_deactivate(self):
if getattr(self, '_p_sticky', False):
return
Persistent._p_deactivate(self)
You could provide any policy you want, without making the policy part
of ZODB.
But, such an object would never again be deactivated (unless
"_p_sticky" is reset). In my proposal, such objects may be
invalidated at transaction boundaries.
This may not be a big problem, as there are probably not too many
objects that have "_p_sticky" defined permanently
("Shared.DC.ZRDB.Connection" and
"Products.CMFCore.Skinnable.ObjectManager" would be examples).
Good point. I left off that you could register a callback on transaction
commit to clear the sticky flag.
Not a nice perspective -- for too reasons:
* When would I register the callback?
When you set the volatile data that needed to be sticky.
Sure, the callback should not need to look at all objects in
the cache to find the sticky ones.
This means, the callback would need to be registered for
each object potentially relevant at transaction boundary time.
Yes, any object that needed to be sticky would need to have a callback
registered.
In principle, all objects in the cache can be relevant...
All objects are sticky?
* The examples above have their "_p_sticky" defined at
class level -- as they make vital use of volatile attributes
and need a garanteed lifetime for them until transaction boundary.
Hm, so stickyness is a property of the class? Why store _p_sticky on
the instance then?
This means we need an additional callback activated after
the cache garbage collection to get rid of the instance
level "_p_sticky" again.
I don't really follow this. I'm not sure I need to.
I have a feeling that there's some deeper issue lurking here.
I'll have to think about this some more.
Some observations:
- This isn't unique to _v_ attributes. An object could
have other non-persistent data that is precious.
- I wonder if an argument could be made than we shouldn't
implicitly deactivate an object that has been accessed in a
a transaction while the transaction is still running.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
