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.
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev

Reply via email to