[DB-SIG] db-api suggestions / zike data classes
Fri, 14 Apr 2000 09:45:06 +0200
"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__
> 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.
> 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
> 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)
Python Pages: http://www.lemburg.com/python/