[Tim Peters, on multidatabase support in Zope3]
>> 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?
> Do you mean an example of a zope.conf that uses it?
Yes, that's all -- just a concrete example. I could have guessed one
(and did later ;-)), but guesses can be wrong.
> From a customer engagement:
> <zodb main>
> path $DATADIR/Data.fs
> <zodb a>
> path $DATADIR/A.fs
Thanks! That did the trick.
> We decided to use the section names for the database names.
> This was to avoid changing ZODB. I'm not sure that that was
> a good idea.
Let's change it.
> This approach has two disadvantages:
> - Because section names are case insenstive,
> database names end up being lower case, whether we
> want them to be or not.
> - It may not be obvious that the section name
> is also the database name.
It isn't obvious -- and unlike for other <zodb> keys, a user can't
look in ZODB's component.xml now to find out anything about this
usage. They can, e.g., look there to see that they can specify
cache-size, that it's an integer, and that it defaults to 5000. They
can also find helpful <description> sections for many keys. Using the
section name is pure out-of-the-blue magic in contrast.
> I'm really unsure about whether this is a disadvantage. I'm not sure if:
> name main
> path $DATADIR/Data.fs
> name a
> path $DATADIR/A.fs
> is better or worse than the first version.
I think it's worse, but mostly because a key with name "name" is also
an option in _related_ sections, but with unrelated meaning. For
example, if you had a nested <zeoclient> section there it could also
have specified a "name" key, which would have nothing to do with the
<zodb> key named "name". Nesting options with the same name gets
confusing quickly. OTOH, I would like the explicit key better if it
had a different name, say
> I'm inclined to think that any time you have sections of the same type, it
> is desireable to give them names, in which case we might be tempted
> to list the names twice.
Sounds orthogonal to me. If it's desirable that whenever multiple
sections of the same type appear, they must be given names, that's
fine, but the way to enforce or encourage that isn't to make all
sections that may appear more than once give some _meaning_ to the
section name. It was just expedient in this specific case, right?
> I'd be happy to plumb this through the factories open method. It would
> seem to me that we only need to be able to pass a databases argument.
> The factory presumably knows it's own name. It could then pass the
> databases dict and the name to the DB constructor.
If I change the <zodb> config to say there's a new optional key for
the multidatabase name (like the "multidb-name" key in the made-up
example above), then the factory will have the same access to that as
it has for other existing ZConfig-specified keys (like cache-size).
BTW, I think there's a related buglet in Zope3's multi_database():
name = factory.name or ''
db.database_name = name
Defaulting to an empty string for "the name" is really a bit of abuse,
since the documented default database_name for ZODB.DB is "unnamed",
and I doubt Zope3 documented that it changed this default ;-). An
explicit ZConfig key here would supply that correct default.
> I haven't looked at Chris's changes. I was pretty happy that the
> changes we made in Z3 were fairly localized and small.
Adding the optional new key to the <zodb> config, and threading the
`databases` arg thru ZODB's config.py, are also small changes.
>> 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.
> OTOH, this feature has hardly been used in Z3. I added to ZODB
> because I had been meaning to for some time ad because we needed
> it for a customer. I don't think anyone else has used it, so I don't
> think there's much established pattern in Z3. Then again, I'm not
> sure, except for the case insentitivity issue that we didn't
> do it the best way. I'd much rather revisit the case insenstitivity
> of section names in ZConfig. I think that if ZConfig section names
> were case sensitive or at least case preserving, I'd be happy with
> the approach we took.
Note that if we add an explicit new key, the case issue goes away (for
this specific new option) at once.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -