[Zope-dev] ZODB: interface for walking object graph?

[Andrew M. Kuchling]

Michel Pelletier writes:
>It's not too bad, although you are correct that allways get more complex
>and never less.  We have generally been able to avoid incredibly complex
>setstates because we try to not evolve an object to incredibly, as
>opposed to engineering a new kind of object that abstracts out or
>delegates or whatever.

I don't think we can guarantee that on our project.  Right now we're
looking at various object databases, most notably POET, Versant, and
ZODB, to serve as the primary data store for our project.  We're
storing business objects, and therefore we can't predict how the
objects will need to evolve in future.  For example, we started out
some months ago saying that .cost is just a numeric value or None.
Now we've done some more requirements based on experience gained since
then, and our cost requirements are now laid out in a 10-page
document.  Requiring that new classes be created to handle such
changes means we'll end up with a *lot* of baggage to drag around, 

>Also, if you just want to add an attribute you can add a shared instance
>attribute to the class definition.  We do this alot to avoid changing

Jim mentioned that in conversation; it doesn't work if the instance
attribute is something mutable like a list that gets appended to, so
it's not a fully general solution.

>Which makes me thing you would want to do something like this analgously
>to UNIX 'single user mode', ie, shut down your site, and run a single
>thread to execute this method of yours (immagine, for example, what

Very probably this will be necessary.  But my point is that there's no
way to re-use the traversal logic that lives in pack(), so you have to
re-impelement the traversal logic.

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
K is for KENGHIS KHAN. *He* was a very *nice* person. History has no record of
him. There is a moral in that, somewhere.
    -- Harlan Ellison, "From A to Z in the Chocolate Alphabet"