[ZODB-Dev] Migrating classes in ZODB 3.5.1

[Tim Peters]

[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 ;-)