[Zope3-dev] zodb __parent__ and weakref

Shaun Cutts shaun at cuttshome.net
Fri Feb 24 22:17:42 EST 2006


> You need to get into the habbit of CC'ing in the list you're replying
> too...

Sorry -- I was thinking that, if this was not a problem w/ ZODB and
external objects, but I've missed something in implementation, maybe I
should have been communicating on Zope3-users instead. Now I don't know
if I've communicated clearly enough to conclude this yet.

> shaunc at speakeasy.net wrote:
> > The data is in Postgres, but I already have a python data
> marshalling/demarshalling/business logic used by other processes, so I
> want to use this interface with ZOPE as well.
> Okay, and what is this interface?

Do you want to see the *whole* interface ? :) I would think it would
suffice to say: it has interfaces to query the database and return
python objects constructed from the data, and various "business logic"
interfaces that trigger creation of new data in the database.

Zope is only one client. Others will be interacting with the database.

> > Should I be trying to inherit from Persistent rather than
> __setstate__? ... perhaps there is a way as flagging a member
> Or that I want to control refresh myself?
> I don't see what implementing IContainer has to do with Persistent,
> __getstate__ or __setstate__... or am I missing something?
I'm only implementing a prototype now, but in production, the database
will have >=30 million objects in it after 2 years of use. For this
reason, and because the db will be changing outside, it doesn't seem
sensible to store the db objects in ZODB. This was also the opinion in
zope3-users when I asked about this earlier.

Instead I want to have a container which queries the database for data
itself, but avoids having these objects be put in the zodb, even if it
itself is in the zodb.

You are saying that it isn't a good approach to implement __getstate__
and __setstate__... but I don't see why this should be so? Can anyone
explain why they are called so often? It seemed from other threads that
the danger would rather be that your data doesn't get stored at all if
you don't explicitly set _p_changed (or whatever its called)....

I've attached a version of my attempted implementation (cleaned up from
the post in <[Zope3-Users] newbie design questions for UI to external

> > I thought that overriding __getstate__ and __setstate__ simply
> pythons default versions of these, which would be called just as often
> my versions. I guess perhaps the default versions are especially
> because they just pass the instance dictionary back and forth(? -- but
> then what does ZODB do with the instance dictionary? Why does it ask
> it if the object itself is ok?)
> Don't worry about any of these things, just don't try and implement
> anything funky, you don't need to and you're likely to get hurt, as
> you've found...
How should I implement this differently, or what bad assumptions am I
making? To my mind, __getstate__ and __setstate__ are the normal way to
control persistence in pickle-using python, so "funky" is in the eye of
the beholder.

- Shaun

> Chris
> --
> Simplistix - Content Management, Zope & Python Consulting
>             - http://www.simplistix.co.uk

More information about the Zope3-dev mailing list