Re: persistence and __setstate__

Jeremy Hylton wrote:
>>>>>>"BAW" == Barry A Warsaw <[email protected]> writes:
>>>>>>"JH" == Jeremy Hylton <[email protected]> writes:
>>>>>>"FG" == Florent Guillaume <[email protected]> writes:
>>>>>>
> 
>   JH> An object is always changed when its __setstate__() method is
>   JH> invoked, except perhaps for some degenerate cases.  It would be
>   JH> 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.
> 
>   BAW> So that means that "schema" updates have to happen external to
>   BAW> the object, because you can't update in __setstate__ and have
>   BAW> that update persist?  Which means if you say, added an
>   BAW> attribute to Foo objects in your database, you'll need a script
>   BAW> to troll through the database, looking for instances of Foo,
>   BAW> make the change, commit them and move on.  That could be more
>   BAW> expensive than an on-demand update.
> 
> If you put code in the __setstate__ to handle object evolution, that
> code will be executed every time the object is loaded until there is a
> transaction that also modifies the object.  Doesn't sound too
> pleasant, but also sounds unavoidable.
> 
> Here are some sketches of other approaches:
> 
> - The database could provide a mechanism to register an object
>   transform function that is executed when an out-of-date object is
>   loaded.  The transform could execute in a separate transaction.  The
>   hardest part is probably providing a means to identify which objects
>   are out-of-date, presumably some kind of class revision id.
> 
> - It should be possible to provide some workaround to register an
>   object as modified within its __setstate__().  It's certainly
>   possible to explicitly register the object with the Connection,
>   although that doesn't mark it as changed.  But we could add some
>   hacks.
> 
> A potential concern for any solution: If the object is updated on
> demand, it is probably important to execute the change as a separate
> transaction.  If you don't, then the object update gets mixed in with
> arbitrary updates to other objects, which unnecessarily complicates
> undo.
> 
> Jeremy
> 
> 
> _______________________________________________
> Zodb4-dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/zodb4-dev
> 
> 



-- 
Jim Fulton           mailto:[email protected]       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org