Re: [Zope-dev] Mountpoints
Tim Peters wrote: [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=38626r1=38574r2=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? Do you mean an example of a zope.conf that uses it? From a customer engagement: zodb main filestorage path $DATADIR/Data.fs /filestorage /zodb zodb a filestorage path $DATADIR/A.fs /filestorage /zodb 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. 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. I'm really unsure about whether this is a disadvantage. I'm not sure if: zodb name main filestorage path $DATADIR/Data.fs /filestorage /zodb zodb name a filestorage path $DATADIR/A.fs /filestorage /zodb is better or worse than the first version. 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. 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'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. 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. I haven't looked at Chris's changes. I was pretty happy that the changes we made in Z3 were fairly localized and small. 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. Jim -- 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: [Zope-CMF] Better DeprecationWarnings (was Re: SVN: CMF/trunk/CMFDefault/Portal.py - reverted Portal.py change of r39125 to fix BBB temporarily)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: Tres Seaver wrote: Note that I have just figured out that we can make DeprecationWarnings more useful by passing the 'stacklevel' argument to 'warnings.warn'; passing a value of 2 for that argument causes the warning to be reported against the *caller* of the code issuing the warning, which makes it possible to find and remove the deprecated use. Oooh, coool. Reckon it'd be a good idea if I changed all the deprecation warnings in Zope to do the same? +10. I've always found them totally useless 'cos they don't tell you where they come from and so you can't fix them... Bit like the random ZODB errors when it no longer has the class for some long-forgotten object burried deep in an opaque pickled data structure which you have no hope of ever finding and deleting... but I digress ;-) Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDV7I2+gerLs4ltQ4RAiTPAJ9ARNJ9C33+BrFMfD7bIgoMNSryQACgtGc5 nzgXeHE9NTZ79BQ5dF9rkN8= =B+U3 -END PGP SIGNATURE- ___ 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: [Zope-CMF] Better DeprecationWarnings (was Re: SVN: CMF/trunk/CMFDefault/Portal.py - reverted Portal.py change of r39125 to fix BBB temporarily)
[Tres Seaver -- I think; I'm missing context for this email] Note that I have just figured out that we can make DeprecationWarnings more useful by passing the 'stacklevel' argument to 'warnings.warn'; passing a value of 2 for that argument causes the warning to be reported against the *caller* of the code issuing the warning, which makes it possible to find and remove the deprecated use. I can recommend the approach I use in ZODB. There's a utility module in ZODB, containing (among other things) functions like this one: # Raise DeprecationWarning, noting that the deprecated thing will go # away in ZODB 3.6. Point to the caller of our caller (i.e., at the # code using the deprecated thing). def deprecated36(msg): warnings.warn(This will be removed in ZODB 3.6:\n%s % msg, DeprecationWarning, stacklevel=3) So every gimmick that's going to go away in ZODB 3.6 imports `deprecated36` from the utility module, and calls it with an appropriate message. As an intended bonus, when I release ZODB 3.6 I can just grep for deprecated36 to _find_ the code that's supposed to go away (I also annotate tests and docs that should go away with deprecated36). Using a common function also ensures that every deprecation warning starts with the same string (identifying the release in which the thing will go away). Note: sometimes _internals_ use deprecated gimmicks in order to support deprecated gimmicks too, and then stacklevel=3 is too small. It's happened so rarely in ZODB that I haven't tried to do something about that yet. ___ 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] Mountpoints
[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? [Jim Fulton] 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 filestorage path $DATADIR/Data.fs /filestorage /zodb zodb a filestorage path $DATADIR/A.fs /filestorage /zodb 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: zodb name main filestorage path $DATADIR/Data.fs /filestorage /zodb zodb name a filestorage path $DATADIR/A.fs /filestorage /zodb 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 zodb multidb-name main filestorage path $DATADIR/Data.fs /filestorage /zodb zodb multidb-name a filestorage path $DATADIR/A.fs /filestorage /zodb 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. Right. 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
