Re: persistence and __setstate__

>>>>> "JH" == Jeremy Hylton <[email protected]> writes:

>>>>> "FG" == Florent Guillaume <[email protected]> writes:

    FG> + /* Prevent the object from being registered as changed.  + +
    FG> If the object is changed while it is being unghostified, + it
    FG> should not be registered with the data manager as + a changed
    FG> object.  The easiest way to prevent this is + to mark it as
    FG> already changed, which implies it is + already registered.  +
    FG> */

    FG> Doesn't that mean that if an object is changed during its
    FG> __setstate__ but not after, those changes won't get persisted
    FG> (because just after __setstate__ the object reverts to
    FG> UPTODATE) ?

    JH> Yes.

    JH> An object is always changed when its __setstate__() method is
    JH> invoked, except perhaps for some degenerate cases.  It would
    JH> be unacceptable to mark an object as changed every time it is
    JH> loaded.

    FG> So won't all objects that upgrade themselves in __setstate__
    FG> keep being upgraded whenever they are reloaded, until they are
    FG> modified from outside __setstate__ ?

    JH> Yes.

So that means that "schema" updates have to happen external to the
object, because you can't update in __setstate__ and have that update
persist?  Which means if you say, added an attribute to Foo objects in
your database, you'll need a script to troll through the database,
looking for instances of Foo, make the change, commit them and move
on.  That could be more expensive than an on-demand update.

-Barry