Hi All, Get this error on startup with one project I've just moved to Zope 2.9.3: File "/usr/local/zope/2.9.3/lib/python/Zope2/Startup/datatypes.py", line 175, in createDB return ZODBDatabase.open(self, databases) File "/usr/local/zope/2.9.3/lib/python/ZODB/config.py", line 105, in open databases=databases) File "/usr/local/zope/2.9.3/lib/python/ZODB/DB.py", line 262, in __init__ raise ValueError("database_name %r already in databases" % ValueError: database_name 'packed' already in databases I still seem to be able to access stuff in this database just fine so I don't know what's going on... Any ideas greatfully received... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote at 2006-6-23 17:12 +0100:
Get this error on startup with one project I've just moved to Zope 2.9.3:
File "/usr/local/zope/2.9.3/lib/python/Zope2/Startup/datatypes.py", line 175, in createDB return ZODBDatabase.open(self, databases) File "/usr/local/zope/2.9.3/lib/python/ZODB/config.py", line 105, in open databases=databases) File "/usr/local/zope/2.9.3/lib/python/ZODB/DB.py", line 262, in __init__ raise ValueError("database_name %r already in databases" % ValueError: database_name 'packed' already in databases
You see here the new (ZODB 3.6) multi-database support. Something tries to ad the database "packed" to a multi-database that already contains a "packed". This might happen when you mount the same storage at different places into your hierarchy. -- Dieter
Dieter Maurer wrote:
Chris Withers wrote at 2006-6-23 17:12 +0100:
Get this error on startup with one project I've just moved to Zope 2.9.3:
File "/usr/local/zope/2.9.3/lib/python/Zope2/Startup/datatypes.py", line 175, in createDB return ZODBDatabase.open(self, databases) File "/usr/local/zope/2.9.3/lib/python/ZODB/config.py", line 105, in open databases=databases) File "/usr/local/zope/2.9.3/lib/python/ZODB/DB.py", line 262, in __init__ raise ValueError("database_name %r already in databases" % ValueError: database_name 'packed' already in databases
You see here the new (ZODB 3.6) multi-database support.
Something tries to ad the database "packed" to a multi-database that already contains a "packed".
This might happen when you mount the same storage at different places into your hierarchy.
Indeed, and this is a perfectly legitimate use case... I have a Packed.fs and an UnPacked.fs: /content from Packed.fs is mounted to /content of UnPacked.fs /Catalog from Packed.fs is mounted to /Catalog of UnPacked.fs ...for this project, content is managed elsewhere and often imported into Zope, so packing very often is a necessity. Unpacked.fs contains code, user information, etc, which should never be packed. So, two questions: 1. Is this a ZODB or a Zope bug? (ie: which collector do I file this in?) 2. Given that this is an exception being raised rather than a log message, how come everything works fine even after the exception has been reported? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote at 2006-6-26 14:16 +0100:
... You see here the new (ZODB 3.6) multi-database support.
Something tries to ad the database "packed" to a multi-database that already contains a "packed".
This might happen when you mount the same storage at different places into your hierarchy.
Indeed, and this is a perfectly legitimate use case...
I have a Packed.fs and an UnPacked.fs:
/content from Packed.fs is mounted to /content of UnPacked.fs /Catalog from Packed.fs is mounted to /Catalog of UnPacked.fs ... So, two questions:
1. Is this a ZODB or a Zope bug? (ie: which collector do I file this in?)
I do not know, yet. We are still using ZODB 3.4 and multi-database support was added in ZODB 3.6. But, I expect it is a Zope bug because both of your mounts could (and almost surely should) use the same database and connection. Both Zope and ZODB use the same collector. ZODB bugs get the category "database". I would file the bug report in this way (Zope collector with category "database") even if it is not a ZODB error (at least it is database related).
2. Given that this is an exception being raised rather than a log message, how come everything works fine even after the exception has been reported?
I do not know -- as I did not yet analyse such a problem. -- Dieter
participants (2)
-
Chris Withers -
Dieter Maurer