Tres Seaver wrote at 2007-8-9 10:40 -0400:

... Copy the 'Components/BTree' directory from a Zope 2.7 checkout into your $SOFTWARE_HOME/lib. Copy the 'setup.py' from Zope 2.7, and hack it apart to include only the bits which built the old BTrees. Then run that new setup_old_btrees.py script.

The reason that Jim dropped support for the old "BTree" was to save time by not converting them to the new "type = new style class" paradigme which is now used by "Persistent". It is likely that "BTree" will not work in a new (post Zope 2.7) environment even if build anew. -- Dieter

This is just an idea, but zeo is backwards compatible right? So perhaps you could connect a 2.7 client to a 2.8 zeo server and as long as you know the oids of the intSets you should be able to load them and do your conversion. Laurence Chris Withers wrote:

Dieter Maurer wrote:

...

The reason that Jim dropped support for the old "BTree" was to save time by not converting them to the new "type = new style class" paradigme which is now used by "Persistent".

It is likely that "BTree" will not work in a new (post Zope 2.7) environment even if build anew.

Yeah, that much I feared :-(

Hmmm... how would I go about writing a python class that could be used in unpickle the persistent data for the intSet objects that are there?

I'm thinking something along the lines of create intSet.py something like as follows and putting it somewhere on the PYTHONPATH:

class intSet(Persistent):

def __setstate__(self,...): ...

Would that work?

cheers,

Chris

Chris Withers wrote:

Laurence Rowe wrote:

...

This is just an idea, but zeo is backwards compatible right? So perhaps you could connect a 2.7 client to a 2.8 zeo server and as long as you know the oids of the intSets you should be able to load them and do your conversion.

An interesting idea, assuming it works, how would I load the objects, change them to the correct (new) type and then save them?

cheers,

Chris

Assuming that the 2.7 client won't be able to read 2.8 BTrees, then in a 2.8 client iterate over everything in the db and save a list of oids (obj._p_oid) of everything of that class. This might be easier iterating over the filestorage directly. To avoid having to update the references to these classes (which hold the referenced class as well as the oid) you will need to make the new class available in the old location through monkey patching. Then in the 2.7 client for each oid in the list: * load the object (through the storage api) * create an object of your new python implementation * save new object as that oid through the storage api Laurence

Dieter Maurer wrote:

Laurence Rowe wrote at 2007-8-10 15:34 +0100:

...

... Assuming that the 2.7 client won't be able to read 2.8 BTrees

A 2.7 client is able to read *and* write "BTrees".

"BTrees" already exist for a very long time; even very old Zope versions can read and write them.

I know that :-) I was just taking the worst case scenario that the pickle format might have changed with the 2.8 release. That seems unlikely though on a second thought.

Chris Withers wrote at 2007-8-10 07:38 +0100:

... I'm thinking something along the lines of create intSet.py something like as follows and putting it somewhere on the PYTHONPATH:

class intSet(Persistent):

def __setstate__(self,...): ...

Would that work?

No. Both "Persistent" and "intSet" come with their own C level attributes. Therefore, Python does not allow them to be combined through subclassing. -- Dieter

Chris Withers wrote at 2007-8-11 09:59 +0100:

... I'm not subclass intSet in the above, I'm rewriting intSet as a python class that subclasses persistent, and then decoding the state in the setstate method...

You are right -- sorry for not reading carefully enough. That may work -- if you can decode the pickle state. -- Dieter