M.-A. Lemburg wrote: >Mario Frasca wrote: > > >>On 2006-1121 16:23:26, M.-A. Lemburg wrote: >> >> >>>Mario Frasca wrote: >>> >>> >>>>[...] it would be nice (I mean, I think it would) >>>>if also the logging policy would be stated in the db-api2++ >>>> >>>> >>>I'm not really sure what logging has to do with the DB-API. >>> >>>Could you explain ? >>> >>> >>[....] >>as I see it, logging has to do with every module, so since there is a >>standard logging module, my feeling is that there could be also a >>standard logging policy... >> >> >Whether or not module authors use the logging module should >really be up to them and not be required by the DB-API. > >Note that many database modules are written as C extensions >and this makes it hard for them to use the logging module >as there is no C API for it which could be used, AFAIK. > > >
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? Chris _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
