Dieter Maurer wrote:
Jim Fulton wrote at 2006-10-6 12:10 -0400:
...
I'm a little uneasy about baking this policy so deeply into
the infrastructure. I wonder if the use case can be handled
another way.
A persistent object can override _p_deactivate. For example:
def _p_deactivate(self):
pass
prevents an object from being turned into a ghost unless it is
invalidated.
I think that
this will not work -- unless more drastical changes are done to
"persistent":
When we invalidate an object, it must get deactivated.
Now, currently invalidating a cache entry calls
the object's "_p_invalidate" which calls
"Per_set_changed(obj, NULL)" which uses "_p_deactivate"
for the deactivation.
With a definition like the above, the object will never
again be deactivated -- not even when it is invalidated.
That is clearly a bug that is easily fixed.
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.
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
