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