[ZODB-Dev] _p_changed in __setstate__

[Greg Ward]

On 25 May 2001, Dieter Niggeler said:
> a persistent class containing a non persistent attribute dictionary
> overrides the method '__setstate__(self)' in order to extend the
> dictionary by further attributes while loading object's state. To advice
> the persistence mechanism to make the object persistent, object's
> self._p_changed is set 1, unfortunately this change is lost.
> Somewhere in the code between _p_changed is set back to 0 without making
> the state persistent.

I have observed this "feature" too.  I can understand why it happens;
after __setstate__(), presumably the object is "just-loaded" and hasn't
been changed.  However, if __setstate__() makes changes it would be nice
for them to get committed, which currently won't happen unless something
else in the object changes later.

My response to this is to avoid doing lots of work in __setstate__(),
since you might have to repeat it every time the object is loaded until
something else causes its _p_changed to be set (and the object
committed).  Serious database evolution should be done in an external
script, anyways, not in __setstate__() (IMHO!).

        Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org