[Tim Peters]
>> I'm not familiar with "broken objects" in newer ZODBs, and didn't
>> find any docs apart from the docstrings in broken.py. ...
[Victor Safronovich]
> But "New broken object support." is not supported by Zope, it uses in
> DBTab.ClassFactories.zopeClassFactory (removed in the trunk)
Tim Peters wrote:
[Tim Peters]
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
On 11/9/05, David Binger <[EMAIL PROTECTED]> wrote:
>
> On Nov 9, 2005, at 10:37 AM, Jeremy Hylton wrote:
>
> > 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
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.
>
[Tim Peters]
>>> 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.l
Stephan Richter wrote:
On Wednesday 09 November 2005 11:00, Tim Peters wrote:
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:
On Nov 10, 2005, at 4:30 AM, Lennart Regebro wrote:
This may not help, but anyway. :)
In Zope, I did this: I moved the class to the module I wanted it. I
also kept a "dummy class" in the old place like so:
from newplace import class
so that the old objects worked. Then I wrote a script to g
On Nov 10, 2005, at 5:09 AM, Syver Enstad wrote:
Thank you Stefan. I am right if I suppose that the reason this
fixes all references is that it saves all persistent objects in the
database? Will this also fix references to persistent objects in
non persistent objects stored in the databas
On 11/10/05, Syver Enstad <[EMAIL PROTECTED]> wrote:
> That sounds good. How do you recreate every object in the ZODB?
I didn't, only the ones that needed. I did that by traversing all
object containers and seeing if the object was of the right type, and
if it was, I deleted it and recreated it fr
Lennart Regebro wrote:
This may not help, but anyway. :)
In Zope, I did this: I moved the class to the module I wanted it. I
also kept a "dummy class" in the old place like so:
from newplace import class
so that the old objects worked. Then I wrote a script to go through
the ZODB and recreate
Stephan Richter wrote:
On Wednesday 09 November 2005 11:00, Tim Peters wrote:
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:
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
David Binger 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
This may not help, but anyway. :)
In Zope, I did this: I moved the class to the module I wanted it. I
also kept a "dummy class" in the old place like so:
from newplace import class
so that the old objects worked. Then I wrote a script to go through
the ZODB and recreate every object. I then cou
Syver Enstad wrote:
Okay, so as far as I can see one has to either install a custom
classfactory method on the DB instance that maps from old to new
locations or hack sys.modules to refer to the new location by the old name.
Well, you could always open your Data.fs in a text editor and do a
g
On Nov 9, 2005, at 3:03 PM, Dieter Maurer wrote:
You can do this in an update script but not in
"classFactory". "classFactory" does not know anything about
the origin of the reference or even the object.
It only knows connection, modulename and globalname.
I'd prefer a script, but connection,
On Nov 9, 2005, at 12:25 PM, Jeremy Hylton wrote:
I suppose you could run a separate thread that performed this
conversion in parallel with other activities. There's a bit of a
coordination problem to make sure you're done. It seems other
application code would need to use the old class defin
David Binger wrote at 2005-11-9 10:11 -0500:
> ...
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 effic
On Nov 9, 2005, at 10:37 AM, Jeremy Hylton wrote:
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.
You do need to do this to find the references (using
[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.
>
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 (usua
Dieter Maurer wrote:
Syver Enstad wrote at 2005-11-7 11:51 +0100:
In ZODB 3.2 I can replace the _classFactory method on DB and locate the
renamed/moved class by other means (a lookup table that maps old module
classname pairs to another class in another module). If I change
attributes of the
Hello Tim Peters,
Tuesday, November 8, 2005, 8:26:00 PM, you wrote:
TP> I'm not familiar with "broken objects" in newer ZODBs, and didn't find any
TP> docs apart from the docstrings in broken.py. Brief overviews of new
TP> features often appear in NEWS.txt, but the news for ZODB 3.3a3 just says
Syver Enstad wrote at 2005-11-7 11:51 +0100:
>In ZODB 3.2 I can replace the _classFactory method on DB and locate the
>renamed/moved class by other means (a lookup table that maps old module
>classname pairs to another class in another module). If I change
>attributes of the persistent instance it
[Syver Enstad]
> In ZODB 3.2 I can replace the _classFactory method on DB and locate the
> renamed/moved class by other means (a lookup table that maps old module
> classname pairs to another class in another module). If I change
> attributes of the persistent instance it will be saved with the new
In ZODB 3.2 I can replace the _classFactory method on DB and locate the
renamed/moved class by other means (a lookup table that maps old module
classname pairs to another class in another module). If I change
attributes of the persistent instance it will be saved with the new
class name instead of
26 matches
Mail list logo
