[DB-SIG] db-api suggestions / zike data classes

[M.-A. Lemburg]

"Michal Wallace (sabren)" wrote:
> 
>   I've actually gotten most of it done (coming soon to sourceforge),
> but I've hit a couple snags because some things a scheme like this
> needs are missing from the (otherwise excellent) API.  Anyway, I
> thought I'd bounce some ideas off the group:
> 
> -----------------------
>  module - agnosticism
> -----------------------
> 
>   First, if I'm just looking at some random connection object, and I
> use it to create a cursor object... How can I get the fieldtypes out
> of the description? The fieldtypes are arbitrary values that have to
> be compared against something back in the module's namespace... But
> since this is a random connection object, *I don't know what module
> to look in!!!*
>
>   I'm testing with MySQLdb and ODBC.Windows. With MySQLdb, the task
> is simple: module = dbc.__class__.__module__ ... But with ODBC.Windows,
> and (I suspect) any other pure C/C++ module, there IS no .__class__
> attribute.
> 
>   My workaround for ODBC.Windows was to create a wrapper class/module
> in python (which also brings ODBC.Windows quite a bit closer to the
> DB-API 2.0 standard)... But wouldn't it be nicer if either
> 
>    a) all Connection objects had to have a .__class__ , or:
>    b) STRING, NUMBER, etc were part of the Connection class?

+ c) all error objects

That's the way I do it too.
 
> -----------------------
>   autonumbers
> -----------------------
> 
>   Suppose I have an autonumber / auto_increment / whatever field. I
> run an INSERT statement. How do I get the generated number? As far
> as I can tell, I have to use a module-specific function call. Wouldn't
> this be a fairly useful process to standardize?

Nope... various DBs have different concepts here, e.g. MySQL uses
a hack to allow you to query the last inserted row in an INSERT
statement. Other DBs have special column types/flags for this.

Use max(id) and some algorithm instead (see my other post) --
its portable, works everywhere and usually does the trick pretty
well.

> -----------------------
>   table names
> -----------------------
> 
>   I personally don't have any particular need for this at the moment,
> but I'm sure it would be nice to have down the line: dbc.tables() to
> give a list of tables?  Possibly even dbc.queries() or dbc.sprocs()
> for providers that had queries and stored procedures.. I'm guessing
> most modules have something like this already, but it's no fun without
> a standard. :)

You mean catalog functions... uhm, we could simply use the
ODBC standard names for these -- together with their return
value strategy: as result set. But then, it would introduce
extra complexity for *all* DB interfaces -- not sure this
would be liked by the interface writers.
 
Note that the ODBC catalog functions are nothing other than
hidden DB-specific SQL statements which get executed... 
every DB interface could emulate these easily.

>   Anyway, I'm probably going to come up with a proposal for actual
> syntax and stuff, and make some wrapper modules just to get my classes
> working for now, but I'd really like to talk about the issues involved
> in updating the standard. (I'm willing to help code changes, too, btw)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/