[Zope3-dev] class lifecycle management/missing attributes

[Peter Simmons]

Hi,

Just out of interest why is an upgrade script like Tres is suggesting?

We schedule upgrades so that users aren't using the system, is that not 
possible for your system?

I figure there is a good reason but I can't think of it and was wondering.

Cheers,
Pete

Garrett Smith wrote:

>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? 
>
> -- Garrett
>
>_______________________________________________
>Zope3-dev mailing list
>Zope3-dev@zope.org
>http://mail.zope.org/mailman/listinfo/zope3-dev
>
>
>  
>

-- 
Peter Simmons
Senior Consultant                  BCMPweb Limited
+64 21 676 909                      +64 9 267 4676
pete@bcmpweb.com            http://www.bcmpweb.com