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
line 107, in __call__
    return Script.__call__(self, *args, **kw)
line 306, in __call__
    return self._bindAndExec(args, kw, None)
line 343, in _bindAndExec
    return self._exec(bound_data, args, kw)
line 162, in _exec
    result = f(*args, **kw)
  File "Script (Python)", line 22, in logged_in
"/home/chrism/software/Trunk/lib/python/ZPublisher/HTTPRequest.py", line
1214, in __getattr__
    v = self.get(key, default, returnTaints=returnTaints)
"/home/chrism/software/Trunk/lib/python/ZPublisher/HTTPRequest.py", line
1174, in get
    if callable(v): v = v()
"/home/chrism/software/Trunk/lib/python/Products/Sessions/SessionDataManager.py", line 
93, in getSessionData
    return self._getSessionDataObject(key)
"/home/chrism/software/Trunk/lib/python/Products/Sessions/SessionDataManager.py", line 
180, in _getSessionDataObject
    ob = container.new_or_existing(key)
"/home/chrism/software/Trunk/lib/python/Products/Transience/Transience.py", line 176, 
in new_or_existing
    item  = self.get(key, notfound)
"/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
  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
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

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to