On 11/9/05, David Binger <[EMAIL PROTECTED]> wrote:
> On Nov 9, 2005, at 9:21 AM, Syver Enstad wrote:
> >>> What I want to do is just update the persistent instance so that
> >>> it will
> >>> load from the new module/ new class after I have done a one time
> >>> update
> >>> of the database.
> >> I fear this will not work.
> >> For efficiency reasons, the class designator (usually a
> >> module, classname tuple) is stored both in the object itself
> >> and in persistent references. While you will be able
> >> to modify the object's class the persistent references will
> >> only change when the containers are stored into the ZODB.
> 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.
How do you find all the references? It seems like you would need to
execute a transaction that iterated over every object in the storage
and searched the pickle for references to the class.
I can imagine the update transaction taking a really long time to run,
which increases the possibility that it will get a conflict error.
Maybe it's a resolvable conflict, but not using the current mechanism.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org