←
→
emperor: (Default)
Add MemoryShare This Entry

PEP 249 sucks

posted by [personal profile] emperor at 05:47pm on 02/06/2008 under , ,
The python interface to databases is increasingly irking me; I have a load of working code that talked to an Oracle database (via cx_Oracle), that I now want to make talk to a Postgresql database (via pgdb). This is far too much pain. Firstly, there are 5 different parameter styles for python database modules (and the two modules concerned use different ones), secondly there seems to be no specification as to how types should be returned - so while cx_Oracle returns date objects (sensibly!) for date columns, pgdb returns strings instead (why???).

Bah.
←
→
There are 5 comments on this entry. (Reply.)
 

(no subject)

posted by [identity profile] mostlyacat.livejournal.com at 10:23pm on 02/06/2008
Ah - here's what you need to do...
[link] [reply]
emperor: (Default)

(no subject)

posted by [personal profile] emperor at 10:32pm on 02/06/2008
You are very strange sometimes, [livejournal.com profile] mostly_a_cat...
[link] [parent] [reply]
 

(no subject)

posted by [identity profile] mirabehn.livejournal.com at 10:47pm on 02/06/2008
You are very observant sometimes, my dear [livejournal.com profile] emperor...
[link] [parent] [reply]
 

(no subject)

posted by [identity profile] womble2.livejournal.com at 01:24am on 03/06/2008
I think there must be some rule that generic database APIs have to suck. I implemented the database access module for an application server, talking to databases over ODBC or (in the case of Oracle) OCI, and needed some huge number of workarounds for quirks of specific ODBC drivers. Besides which it seems to be impossible to write portable SQL due to gross divergences from the standard in the most popular implementations.
[link] [reply]
sparrowsion: photo of male house sparrow (string-handling kitten)

(no subject)

posted by [personal profile] sparrowsion at 09:36am on 03/06/2008
Kind of echoing [livejournal.com profile] womble2—by the time you've dealt with porting your SQL to your new backend, things like the parameter styles become incidental. (My experience of this is grafting Firebird support into a program which already handled Oracle and MySQL. If you've already got a class (or other) interface which hides the DB-API from the rest of your program, the headache is entirely in the differences in SQL dialect. Even differences of opinion on paramstyle can be ameliorated by judicious use of a %-substitution to build a query with parameters. Do not go to comp.lang.python for advice, for they will tell you to use SQLAlchemy or some such ORM.)
[link] [reply]

October

SunMonTueWedThuFriSat
      1
 
 2
 
 3
 
 4
 
5
 
 6
 
 7
 
 8
 
 9
 
 10
 
 11
 
12
 
 13
 
 14
 
 15
 
 16
 
 17
 
 18
 
19
 
 20
 
 21
 
 22
 
 23
 
 24
 
 25
1
26
 
 27
 
 28
 
 29
 
 30
 
 31