Chris Clark wrote: > My 2 cents. I agree that logging isn't something that _must_ be part of > a driver but logging is extremely useful. I think we are looking at > another case where we need a higher level manager (along the lines of > the wrapper example) something akin to the ODBC driver manager. In ODBC > an ODBC driver is (almost) completely useless without the driver > manager; under Windows this is part of the OS, under Unix you use > something like unixodbc.org (openlink.com, etc.). The manager object > then performs logging (of course this doesn't prevent each driver having > a completely different set of logging options too). > > There have been a number of suggestions recently, such as the URI for > connect strings that would be perfect for a higher level module that > could be part of the *DBI* api but not part of the _driver_ API. > Currently PEP 249 is just for the driver API (and that is and has been > extremely useful). I would love to see the next spec include an api (and > implementation) for a driver manager that makes life easier for > application developers BUT existing apps should still be able to call > the driver directly and avoid the potential overhead. The driver manager > (I'm sticking with ODBC terms here for simplicity) is essentially a > Decorator pattern. There are existing modules around that could be > looked at so that we don't design from scratch. e.g. > http://sourceforge.net/projects/pythondbo/ has already got a working URI > approach (note I've not used it but the docs are promising). pythondbo > also has some code for attempting to deal with the different param styles. > > Any comments?
Yes, this is the sort of thing I was thinking about. We don't really need to place more burdens on drivers, or require all the drivers to be upgraded -- drivers just need to provide a *little* more information. (And even in some cases probably can be wrapped for that information -- for instance, to get the remote version number of a database often it's just a SQL query.) I also think some things are well outside the possible scope of what can be done here. For instance, standardizing database metadata access. It's mostly bound to the details of the remote database, has little relation to the driver specifically, and needs a lot more maintenance and work and maybe is accessible via different APIs. One could argue that even integrating the different exceptions could be part of this, as databases (and/or drivers) aren't terribly consistent about what kind of exceptions they throw. I doubt they could be made consistent without parsing the text portion of the exceptions. Incidentally, I tried to pull together a few of these things in sqlapi: http://sqlobject.org/sqlapi/ -- but I don't really have the time to push that forward, and I think it's scope is a little too large (e.g., the SQL abstraction layer). -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
