[ZODB-Dev] RE: RE: PersistentMapping
Tim Peters wrote: ZODB/branches/3.5 My newly added tests for PersistentMapping break here; PersistentMapping seems to lack __iter__. (PersistentMapping hadn't been tested at all before.) The suite passes fine on the trunk and the 3.4 and 3.6 branches, but it fails on 3.5. Should __iter__ be added to the 3.5 PersistentMapping, or is it missing for a reason? -- Thomas ___ 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
RE: [ZODB-Dev] RE: RE: PersistentMapping
[Thomas Lotze] ZODB/branches/3.5 My newly added tests for PersistentMapping break here; PersistentMapping seems to lack __iter__. (PersistentMapping hadn't been tested at all before.) The suite passes fine on the trunk and the 3.4 and 3.6 branches, but it fails on 3.5. Should __iter__ be added to the 3.5 PersistentMapping, or is it missing for a reason? Looks it got lost in the branches. PersistentMapping.__iter__ was added in ZODB 3.4.2, just this August: http://mail.zope.org/pipermail/zodb-checkins/2005-August/010225.html Log message for revision 38076: Gave PersistentMapping an __iter__ method. Also gave it some tests (it was woefully untested). ... That got merged to the trunk (at the time) right away: http://mail.zope.org/pipermail/zodb-checkins/2005-August/010226.html Looks like the 3.5 branch got overlooked. Merging rev 38076 from 3.4 branch to 3.5 branch would be fine. ___ 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
RE: [ZODB-Dev] Migration of obsolete BTrees to ZOPE 2.8
[Dieter Maurer] It is no problem as long as you migrate while you are still using a Zope 2.7 (ZODB 3.2) release. I believe (but don't know) that the OP has many distinct, physically distributed installations of their product, involving many distinct databases. I don't know how many many is ;-), or what kind of upgrade strategy would be acceptable, but I'm pretty sure they can't nurse each upgrade along by hand. We added automatic migration code to our old BTree/Intset using code. Right, and I think that's what most other people did too. But we may need an explicit conversion before we finally upgrade to Zope 2.8 -- to get very rarely used objects upgraded as well. ... The migration is trivial as long as BTree and Intset are still available. We use for example the following BTree migration. # backward (pre Zope 2.8) compatibility try: from BTree import BTree as _BTreeOld # DM 2005-08-25: for unknown reasons, this can raise an AttributeError # rather than an ImportError #except ImportError: _BTreeOld = None except (ImportError, AttributeError): _BTreeOld = None from BTrees.OOBTree import OOBTree as BTree ... tree = self._tree if _BTreeOld is not None and isinstance(tree, _BTreeOld): # still an oldy -- upgrade to modern structure self._tree = BTree(tree) msg = 'BTree upgraded' else: msg = 'BTree was already modern' Margie, does this help you? Can you do migration live along these lines, or do you need on offline conversion script, or ...? ___ 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
