Z2 HEAD in rough shape for b/c
Using the HEAD with old databases and code is a real adventure these days for these reasons: - It doesn't start, due to a tiny config bug which I'll check a fix in for shortly. - Many products create instances of the class Persistence.PersistentMapping.PersistentMapping which no longer exists (CMFCore's SkinsTool and CMFDefault DiscussionTool are two of these). These things either need to be migrated somehow to Persistence.PersistentMapping (*before* an update to the HEAD) or we need to provide some sort of b/c alias. That seems tricky given the current source layout. I've added an alias that seems to work: sys.modules['Persistence.PersistentMapping'] = sys.modules['Persistence.mapping'] But this is really odd because I don't know under what circumstance this alias shadows the effect of the line: from Persistence.mapping import PersistentMapping in Persistence's __init__.py module. If there is a shadowing problem with this alias, I'd suggest we go back to the old layout (where there really was a PersistentMapping.py module in Persistence) on the HEAD for sanity's sake. I'm sure there are reasons against this, but the other option is to require every CMF/Plone user to go through a really delicate migration before upgrading to 2.8, which doesn't seem like a good idea. - The HEAD apparently no longer allows URL access to methods that have inherited function docstrings, where older versions did. Lots of things depend for better or worse on this behavior and this breaks a lot of things. They are all shallow fixes (go add a docstring, typically) but it's difficult to figure out where you need to go do this. - The ZODBMountPoint product relies on a method of Connection objects named _getMountedConnection, which apparently no longer exists. This breaks any mounted databases (which breaks dbtab, which breaks sessions, which breaks lots of other things). Hopefully this is simple to fix, I haven't looked yet. - ZopeVersionControl doesn't work anymore due to various ZODB changes. - Various security declarations that used to allow access now deny. Bug reports don't get any more vague than that, but then again nobody's security machinery is any more vague about reporting its reasons for denying access than Zope's. ;-) I can try to make headway on some of this. Is anyone else willing to help? FWIW, after working through (and around) some of these issues I was able to get Plone running on the current HEAD (well, at least plope.com, which uses a lot of Plone), so I can happily report that Zope 2.8 isn't 100% backwards-incompatible yet. ;-) dig-the-hole-and-fill-it-up-again'ly y'rs, - C
[Chris McDonough]
... - The ZODBMountPoint product relies on a method of Connection objects named _getMountedConnection, which apparently no longer exists.
Connection objects never had such a method, but they still do <wink>.
This breaks any mounted databases (which breaks dbtab, which breaks sessions, which breaks lots of other things). Hopefully this is simple to fix, I haven't looked yet.
I expect Shane will look at this in a week or two (when he settles down from moving) -- but can't know that. There was some horrid patching going on in ZODBMountPoint.py, which reached into various ZODB internals and replaced them. Jeremy refactored that, to make MountConnection a subclass of Connection, and MountConnection._getMountedConnection() is still there. There's still horrid patching going on, in that ZODBMountPoint.py reaches into ZODB.DB.DB and forces it to create MountConnection connections instead of Connection connections. Perhaps this isn't being done "soon enough" in whatever exactly it is you were trying. It would probably make most sense to move some of this code into ZODB (instead of replacing ZODB guts by magic). I think Shane wants to do that. I wish I could say it's peculiar that the Zope HEAD tests all pass despite the problems you're finding.
On Mon, 2004-04-26 at 18:06, Tim Peters wrote:
Connection objects never had such a method, but they still do <wink>.
Ya, I figured this out later. ;-)
This breaks any mounted databases (which breaks dbtab, which breaks sessions, which breaks lots of other things). Hopefully this is simple to fix, I haven't looked yet.
I expect Shane will look at this in a week or two (when he settles down from moving) -- but can't know that. There was some horrid patching going on in ZODBMountPoint.py, which reached into various ZODB internals and replaced them. Jeremy refactored that, to make MountConnection a subclass of Connection, and MountConnection._getMountedConnection() is still there.
Right. FWIW, the binding to DB.klass to allow the DB to use the MountConnection happens too late as it stands. But that doesn't matter too much for reasons below.
There's still horrid patching going on, in that ZODBMountPoint.py reaches into ZODB.DB.DB and forces it to create MountConnection connections instead of Connection connections. Perhaps this isn't being done "soon enough" in whatever exactly it is you were trying.
Yes, I fixed this by making the binding happen earlier (during startup). Once I do that, Zope in its default configuration indeed starts and appears to work. But any time an attempt is made to access or store an object in a mounted database (the default Zope sessioning configuration makes use of a mounted database), it falls over. The same code works ok against objects in the main database. You can probably replicate the problem by using the Zope "Shopping Cart" example code (accessible by viewing the Zope default home page without '/manage') For anyone who cares, here's a traceback demonstrating one variation of the symptom: 2004-04-25T22:38:57 ERROR SiteError http://www.plope.com/logged_in Traceback (most recent call last): File "/home/chrism/software/Trunk/lib/python/ZPublisher/Publish.py", line 111, in publish request, bind=1) File "/home/chrism/software/Trunk/lib/python/ZPublisher/mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "/home/chrism/software/Trunk/lib/python/ZPublisher/Publish.py", line 40, in call_object result=apply(object,args) # Type s<cr> to step into published object. File "/home/chrism/var/zopemafia.org/Products/CMFCore/FSPythonScript.py", line 107, in __call__ return Script.__call__(self, *args, **kw) File "/home/chrism/software/Trunk/lib/python/Shared/DC/Scripts/Bindings.py", line 306, in __call__ return self._bindAndExec(args, kw, None) File "/home/chrism/software/Trunk/lib/python/Shared/DC/Scripts/Bindings.py", line 343, in _bindAndExec return self._exec(bound_data, args, kw) File "/home/chrism/var/zopemafia.org/Products/CMFCore/FSPythonScript.py", line 162, in _exec result = f(*args, **kw) File "Script (Python)", line 22, in logged_in File "/home/chrism/software/Trunk/lib/python/ZPublisher/HTTPRequest.py", line 1214, in __getattr__ v = self.get(key, default, returnTaints=returnTaints) File "/home/chrism/software/Trunk/lib/python/ZPublisher/HTTPRequest.py", line 1174, in get if callable(v): v = v() File "/home/chrism/software/Trunk/lib/python/Products/Sessions/SessionDataManager.py", line 93, in getSessionData return self._getSessionDataObject(key) File "/home/chrism/software/Trunk/lib/python/Products/Sessions/SessionDataManager.py", line 180, in _getSessionDataObject ob = container.new_or_existing(key) File "/home/chrism/software/Trunk/lib/python/Products/Transience/Transience.py", line 176, in new_or_existing item = self.get(key, notfound) File "/home/chrism/software/Trunk/lib/python/Products/Transience/Transience.py", line 817, in get b = index.get(k, notfound) File "/home/chrism/software/Trunk/lib/python/ZODB/Connection.py", line 795, in setstate self._setstate(obj) File "/home/chrism/software/Trunk/lib/python/ZODB/Connection.py", line 849, in _setstate self._reader.setGhostState(obj, p) File "/home/chrism/software/Trunk/lib/python/ZODB/serialize.py", line 401, in setGhostState obj.__setstate__(state) SystemError: new style getargs format but argument is not a tuple I haven't worked up the will to dug into the problem any further, but I intend to do so later this week.
It would probably make most sense to move some of this code into ZODB (instead of replacing ZODB guts by magic). I think Shane wants to do that.
I wish I could say it's peculiar that the Zope HEAD tests all pass despite the problems you're finding.
It's understandable because these are all "functional" kinda bugs, dealing with the interaction between pieces of the system and/or the operation of new code against old database state. The unit tests could probably be improved to catch some of them, but nothing will ever be is a thorough as "meat" testing. Most of the time, though, I think I'd prefer that someone else were the meat. ;-) - C
participants (2)
-
Chris McDonough -
Tim Peters