Re: Zope will not start after failed 2.8.1 upgrade
Well, fortunatly I had last nights backup of the Data.fs. Restoring that allowed Zope to be reverted to 2.7.7 and restart. So here is my question. Normally I have been able to upgrade Zope, and if the upgrade had problems, revert to a prior version by simple redirecting the startup and python to the earlier version. Zope 2.8.1 was different. The upgrade, at least on the surface, appeared to alter something in the Data.fs, which prevented reversion to 2.7.7. I would be very interested in any insights into why this is. Was I experience a Zope issue or a Python 2.3.5 issue? The logs have not provided me an insight expect that the Mapping module was missing after the revert, which I don't think was an accurate assessment of the problem. -- Harlow Pinson Indepth Learning Email: hpinson@indepthl.com Phone: 505 994-2135 Fax: 505 994-3603
[hpinson@indepthl.com]
Well, fortunatly I had last nights backup of the Data.fs. Restoring that allowed Zope to be reverted to 2.7.7 and restart.
So here is my question.
Normally I have been able to upgrade Zope, and if the upgrade had problems, revert to a prior version by simple redirecting the startup and python to the earlier version. Zope 2.8.1 was different. The upgrade, at least on the surface, appeared to alter something in the Data.fs, which prevented reversion to 2.7.7.
I would be very interested in any insights into why this is. Was I experience a Zope issue or a Python 2.3.5 issue? The logs have not provided me an insight expect that the Mapping module was missing after the revert, which I don't think was an accurate assessment of the problem.
I doubt anyone can guess with certainty unless they're able to do exactly what you did. My uncertain guess is that a ZODB change is most likely. ZODB 3.4 (which Zope 2.8 uses) is radically different from ZODB 3.2 (which Zope 2.7 uses) in several ways. A relatively minor way that may be relevant here is that the PersistentMapping type moved, from ZODB.PersistentMapping.PersistentMapping (3.2) to persistent.mapping.PersistentMapping (3.4). The database root object is of this type. 3.4 can load an old (3.2) Data.fs because it slams 3.2's 'ZODB.PersistentMapping' into sys.modules as an alias for 3.4's persistent.mapping, but if the root object is written out again, it will reference the correct-for.3.4 class path (persistent.mapping.PersistentMapping), and no pre-3.4 version of ZODB will be able to load that again (unless you slam your own aliases into sys.modules, going in the other direction). If so (and I don't _know_ -- I'm guessing here), you're suffering a consequence of that some classes moved. Because some classes did move, it's intended that you be able to move from 2.7 to 2.8, but it's not intended that you can move back again. In any case, it's always very dangerous to change things without ensuring you have a Data.fs backup first. I'm glad to hear you never got burned before, but you should view that as luck more than as an entitlement <0.5 wink>.
participants (2)
-
hpinson@indepthl.com -
Tim Peters