[Chris McDonough] > There is a wrinkle about performing this merge that eluded my memory > until now. > > To support multidatabases within Zope, it was reasonable to change > ZODB.config.ZODBDatabase to support the heretofore > likely-unused-by-real-world-code "databases" and "database_name" options > that may now be passed into ZODB.DB's constructor: > > http://svn.zope.org/ZODB/branches/blob-merge-branch/src/ZODB/config.py?rev=38626&r1=38574&r2=38626 > > The current blob-merge-branch code depends on this change being > available in the ZODB revision it uses. In case you're interested, the > code that actually makes use of this feature in the zodb-blobs-branch is > in the Zope2.datatypes.DBTab.getDatabase method. > > Is this change acceptable for a merge into the ZODB HEAD?
Turns out that a release of Zope3 has already been made that supports multidatabases, and I'd naturally prefer to follow the lead of a Zope that's already out there. Jim showed me the Zope3 implementation code and an example today. I found the code easily (on Zope3 trunk), but can't for the life of me find anything there that looks like his example. Jim, where is that? The Zope3 code in question is in src/zope/app/appsetup/appsetup.py function multi_database(). Note that they didn't change any ZODB files, instead they give values to a DB's .databases and .database_name attributes after constructing the DB. While that might be questionable in general <cough>, the implementation of multidatabases was meant to be both concrete and public. It's not an accident that ZODB's tutorial tests/multidb.txt doctest explains and exploits details of the concrete implementation -- it's not meant to be abstract. IOW, poking in new values for these attributes isn't considered to be evil. I believe (here's where the example I can't find would nail it) they use the name on a <zodb> section as the DB's database_name. Fred points out that ZConfig section names are case-insensitive, forced to lowercase, so that <zodb CHRIS> and <zodb cHris> have the same name. That's not ideal, and threading these attributes throughout ZODB's config.py instead (as you did) would be a sane way to worm around that. But for right now, I think doing it differently than Zope3 does it would cause needless confusion more than it would help. Enhancing Zope3 and Zope 2.9 in the same way(s) here could make sense. Some mechanics: if we do need to make changes, ya, ZODB trunk is the place to do it. Work on the branch should use ZODB trunk now. When that's as ready to go as it's going to get, let me know and I'll make "an internal release" of ZODB 3.6 so we can use a ZODB tag before merging into Zope trunk. ("An internal release" just means I update ZODB's NEWS.txt, fiddle version numbers and dates in umpteen places, and make a tag so other projects can use that -- it's the tag that's important here; an internal release does not involve making tarballs, Windows installers, announcements (etc), so it's much cheaper and goes much faster (minutes vs hours) than making a public release.) _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )