My favorites | Sign in
Project Home Downloads Wiki
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 18: pyodbc isn't quite DB API 2.0 compliant
1 person starred this issue and may be notified of changes. Back to list
Status:  Complete
Owner:  ----
Closed:  Dec 2008


 
Reported by tarkatronic, Dec 30, 2008
The one issue I've run into is with connection strings. According to PEP 249:

    [1] As a guideline the connection constructor parameters should be
        implemented as keyword parameters for more intuitive use and
        follow this order of parameters:
        
          dsn         Data source name as string
          user        User name as string (optional)
          password    Password as string (optional)
          host        Hostname (optional)
          database    Database name (optional)
        
        E.g. a connect could look like this:
        
          connect(dsn='myhost:MYDB',user='guido',password='234$')

Of course, I realize that implementing this specific interface for ODBC may
be troublesome... plus the fact that this is only a "should", rather than a
"must". Still, it's just one of those things that would be nice. This did
actually cause me some trouble with django-pyodbc, with the way it
constructs its connection strings. You can see a ticket related to that
here: https://code.google.com/p/django-pyodbc/issues/detail?id=18

Preferably I would have refactored it to work as proposed to Django's
psycopg2 adaptor here: http://code.djangoproject.com/ticket/6710  however
that isn't really possible with the current connect interface in pyodbc.

I'm thinking it may also be possible to implement something like this
without breaking API compatibility with the 2.x series. Since currently,
kwargs are not the recommended usage for passing connection strings, then
perhaps if they are used, it could be taken as referring to the interface
mentioned above and otherwise it uses the current pyodbc connect interface.
Dec 30, 2008
Project Member #1 mkleehammer
The reason I originally chose not to do this is because the ODBC connection strings I
work with are usually much more complicated.  I couldn't possibly add all of the ODBC
keywords.

If I can, I'll add keyword parameters and make the first string parameter optional. 
Then you can use either.

In addition to the keywords above, I'll accept any and put them together into the
final connection string.
Status: Investigating
Labels: -Type-Defect Type-Enhancement
Dec 30, 2008
Project Member #2 mkleehammer
Added in 2.1.3

See the updated documentation on the [Module] page.
Status: Verified
Nov 21, 2010
Project Member #3 mkleehammer
(No comment was entered for this change.)
Status: Complete

Powered by Google Project Hosting