[Zope-dev] Re: Mountpoints
Chris McDonough wrote: This merge has been done. Since "zopectl test " no longer appears to do the right thing and I can't seem to get test.py to run anything except the entire test suite, I didn't create any new tests because I wouldn't have had the time to create tests and run them iteratively. Jim merged his new testrunner some time ago. Syntax has changed slightly, see the help (zopectl test -h). You should do for instance: zopectl test -s you.product.name zopectl test -s you.product.name -m module-regexp -t test-regexp Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 )
Re: [Zope-dev] Re: Mountpoints
[Chris McDonough] |> Note that I don't have a strong opinion about this either way but I will > note that at least Zope 2's subclass of the "zodb" config handler will > need to continue to be willing to use the section title as the database > name for backwards compatibility reasons, as people who have older Zopes > will want to use their older config files (which have zodb_db sections > that have section titles, and no "database-name" key) with new Zope > releases. Note that when you look at Zope2's zopeschema.xml's zodb_db config, there isn't a clue there that the section's name is used for something, let alone what it's used for. This lack of discoverability goes away when using an named key, and that's a better long-term place to be. I don't expect that adding an optional named key to config will _stop_ config from doing whatever it wants to do instead. If it does, I agree that would be a problem. ___ 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 )
Re: [Zope-dev] Re: Mountpoints
On Fri, 2005-10-21 at 11:13 -0400, Jim Fulton wrote: > > > > Not really: a DB's database_name was introduced specifically for the > > new-in-ZODB-3.5 multidatabase feature, and has no meaning or use apart > > from its multidatabase role. That's better explained in the ZConfig > > section for the key than in the name of the key, though. > > > > If Jim doesn't object soon, I'll proceed with adding a database-name > > key to ZODB's config. Note that I don't have a strong opinion about this either way but I will note that at least Zope 2's subclass of the "zodb" config handler will need to continue to be willing to use the section title as the database name for backwards compatibility reasons, as people who have older Zopes will want to use their older config files (which have zodb_db sections that have section titles, and no "database-name" key) with new Zope releases. - C ___ 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 )
[Zope-dev] Re: Mountpoints
Tim Peters wrote: [Tim Peters] 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 section there it could also have specified a "name" key, which would have nothing to do with the 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 multidb-name main path $DATADIR/Data.fs multidb-name a path $DATADIR/A.fs [Florent Guillaume] Yes, please. There is already confusion for cache-size, let's not repeat that with another key. Note that "database-name" is more expressive, I think Since the name of the corresponding DB argument is "database_name", and all the docs that exist for this call it "database_name" too, that's hard to argue against ;-) (the "multi" seems like an implementation detail to me). Not really: a DB's database_name was introduced specifically for the new-in-ZODB-3.5 multidatabase feature, and has no meaning or use apart from its multidatabase role. That's better explained in the ZConfig section for the key than in the name of the key, though. > If Jim doesn't object soon, I'll proceed with adding a database-name key to ZODB's config. +1 -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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 )
[Zope-dev] Re: Mountpoints
[Tim Peters] >> 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 section there it could also >> have specified a "name" key, which would have nothing to do with the >> 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 >> >> >> multidb-name main >> >> path $DATADIR/Data.fs >> >> >> >> multidb-name a >> >> path $DATADIR/A.fs >> >> [Florent Guillaume] > Yes, please. There is already confusion for cache-size, let's not repeat > that with another key. Note that "database-name" is more expressive, > I think Since the name of the corresponding DB argument is "database_name", and all the docs that exist for this call it "database_name" too, that's hard to argue against ;-) > (the "multi" seems like an implementation detail to me). Not really: a DB's database_name was introduced specifically for the new-in-ZODB-3.5 multidatabase feature, and has no meaning or use apart from its multidatabase role. That's better explained in the ZConfig section for the key than in the name of the key, though. If Jim doesn't object soon, I'll proceed with adding a database-name key to ZODB's config. ___ 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 )
[Zope-dev] Re: Mountpoints
Tim Peters wrote: 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 section there it could also have specified a "name" key, which would have nothing to do with the 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 multidb-name main path $DATADIR/Data.fs multidb-name a path $DATADIR/A.fs Yes, please. There is already confusion for cache-size, let's not repeat that with another key. Note that "database-name" is more expressive, I think (the "multi" seems like an implementation detail to me). Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 )
