Chris, > 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. > [EMAIL PROTECTED] 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 __getstate__, > __setstate__? ... perhaps there is a way as flagging a member volatile?... > 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 data>. > > I thought that overriding __getstate__ and __setstate__ simply overrides > pythons default versions of these, which would be called just as often as > my versions. I guess perhaps the default versions are especially efficient > because they just pass the instance dictionary back and forth(? -- but > then what does ZODB do with the instance dictionary? Why does it ask for > 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 > _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com