[Zope-dev] Help: __getstate__ overriding

[Syver Enstad]

"Tim Peters" <tim at zope.com> writes:

> That adds something to the BTree that is bound to an attribute of articleDb,
> but still doesn't set _p_changed on articleDb (mutating the BTree does not
> mutate the object containing the BTree).  So far as the *database* is
> concerned, there's still no path from the root object to the BTree your
> __setstate__() created, so the BTree never gets committed.  

So the BTree is not "registered" with the database until _p_changed
and a commit? After that first commit, the BTree is "registered" as
reachable and then when just the BTree is _p_changed I get my changes
saved. Right?

> 
> Calling __setstate__ as a side effect of a persistent load does not, by
> itself, support making changes that persist.  It apparently wasn't designed
> to, either (see the other msgs in this thread, particularly from ChrisM).

I can understand the reasoning behind it, in the way that you don't
want nothing to change on disk when you logically haven't called a
mutating method on your object, just loaded it. But I do think it is
badly broken to not save the changes when I have made additional
changes to the state of the object after load time. Why not just take
the performance hit and be done with it? What do other object
databases do with schema migration issues, f.ex. GemStone?

Now well, I believe I understand why this happens and that is a very
good thing! Thanks to all who have helped me in gaining a better
understanding of ZODB.