[Zope3-dev] class lifecycle management/missing attributes

[Garrett Smith]

Tres Seaver wrote:
> __setstate__ hackery can work, but is fragile:  because the object is
> not marked as modified when changed by __setstate__, it doesn't get
> persisted in the upgraded state.  Write-on-read has scalability
> problems, as well, which also tend to make 'mutate inside an accessor'
> solutions unsatisfactory.

I view a 'deserialize' operation as a constructor proxy -- very much a
write operation.

Is __setstate__ the Persistence deserialize method? Can't _p_changed be
set in that method?

> Our usual practice in the case where a class-scope default won't work
> is to write a script which trolls through the ZODB, converting wayward
> objects as it find them.  Such scripts keep the cruft in ancillary
> code;  not only that, one can typically discard the scripts after
> having run them against each affected ZODB.

I can see an approach like this for a RDB, given their infrastructure
for schema management and evolution. But...yikes...what do you tell
users who get to the unconverted objects before the script does?

> Persistence-means-never-being-able-to-forget-your-mistakes'ly,

Aw...that's not very XPish of persistence ;-)

On the more extreme side, isn't there an ZODB upgrade strategy for
product revisions?=20

 -- Garrett