Hi,
Jim Fulton wrote:
I've created a proposal:
http://www.zope.org/Wikis/ZODB/DecouplePersistenceDatabaseAndCache
I took some time reading it to day (and trying to spot the problem you
mentioned, but I probably failed on that one.)
Here are some lightweight questions just for clarification:
Fundamentally, the persistence framework is about events. Databases and
caches need to be notified of certain events:
Databases would specifically be a data manager when talking
about ZODB databases, right?
Cache implementations will define persistent observers.
The term persistent observer reads (to me) in many cases as
observer for instances of things that subclass
persistent.Persistent is that right? I'd like to change this
wording a bit to make it easier not to confuse this with an
observer that could be made persistent. Minor thing, but I had
to think about it several times while reading the proposal.
The Persistent base class will continue to provide methods _p_deactivate
and _p_invalidate to allow subclasses to override these, when necessary.
I'm very unsure about this (as I'm not very knowledgeable about
Python on anything C-related), but is there any chance this
conflicts with the goal of not having any C-Data defined in
persistent.Persistent? I guess not, as they are methods, but
then again, I don't know for sure.
There will be a PersistentObserver? base class that will act as a
marker. The Persistent implementation will find an object's persistent
observer (if any) by searching it's weak references for an instance of
PersistentObserver?.
I guess that 'getweakrefs(object)' is implemented rather fast in
Python and weakrefs aren't used that much anyway, so the result
would many times be a one-item list. However, the observer has
to be looked up a few times during the life cycle of an object.
Is that a hidden place for performance loss?
The data-manager's accessed method should be called if the object has
been accessed.
Hmm. I haven't found a method named accessed in the whole
ZODB. And definitely not on the IDataManager or
IPersistentDataManager. Is that going to appear within the scope
of this proposal? What does it do?
The persistent attributes _p_jar, _p_oid, _p_changed, _p_serial, and
_p_mtime will still be supported but will be deprecated for a long
deprecation period.
Will this conflict with the goal of not having any C-Data in
persistent.Persistent?
Ok. That's anything that I can come up with. If I didn't find the
problem that you're keeping in your head, maybe you want to share it
with us? (Not wanting to spoil the fun for anybody, but the proposal has
been around for a while, so I guess other people already looked too.)
Christian
--
gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany
www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development
signature.asc
Description: OpenPGP digital signature
___
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
