[DB-SIG] Extending DB-API

[Chris Clark]

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