[ZODB-Dev] Migrating classes in ZODB 3.5.1

[Syver Enstad]

Tim Peters wrote:

>[David Binger]
>  
>
>>Is there something to prevent your update script from setting _p_changed
>>= 1 on every persistent object that contains a reference to an instance
>>of the moved class? I think that if you do that and commit and pack the
>>database, the old module/class references will be purged.
>>
>>If you do this, the sys.modules hacking only has to happen in the update
>>script.
>>    
>>
>
>Stephan Richter was wrestling with a migration script a couple months ago.
>I don't know whether he packaged the code he ended up with for reuse.
>Here's a record of the IRC chat in which details got worked out:
>
>    http://zope3.pov.lt/irclogs/%23zope3-dev.2005-08-25.log.html
>
>Mostly because of that, ZODB 3.6 changed so that if you set _p_changed to a
>true value on a ghost object, the state for the ghost is loaded.  Before
>3.6, setting _p_changed to a true value on a ghost object is ignored (no
>exception, and the object remains a ghost).
>
>In short, setting _p_changed may not be enough.  Before 3.6, _p_activate()
>should be called too (before setting _p_changed; see the IRC log for
>details).
>
>BTW, no version of ZODB 3.6 has been released publicly yet, although current
>Zope 2.9 and 3.2 development use an "internal" 3.6.0b3 release (i.e., it's
>solid enough, but I haven't had time to make/test/publish
>tarballs/installers/news/etc).
>
>[Syver Enstad]
>...
>  
>
>>What I don't like is that this will break for the following case as far 
>>as I see.
>>
>>firstModule.First renamed ->  secondModule.Second
>>
>>Some time later in the database life:
>>New class: firstModule.First.
>>Will be hidden by the machinery that hacks in secondModule.Second under 
>>the old name firstModule.First.
>>    
>>
>
>You'll see I had the same objection in the log referenced above.  A one-shot
>migration script seems doable, but I don't think there's a wholly sane
>approach on the horizon for doing live, lazy, incremental migration
>slobbering over decades ;-)
>  
>
That's quite okay. I am only searching for a way to perform atomic 
offline upgrades with an upgrade script, so that my source code can stay 
clean not having to care about what the database looked like N versions 
ago. Except for my upgrade machinery of course.