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

        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

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.)


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

Attachment: signature.asc
Description: OpenPGP digital signature

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to