On Fri, 2006-11-10 at 11:35 -0500, Art Protin wrote:
> Dear folks,
> On testing and documenting my implementation of the V2 DB API Spec,
> I am bothered
> by my (limited) understanding of what the spec says for the behavior of
> Cursor.description .
> Clearly when a query (or rather an SQL statement) does not produce a
> result, .description should be None. However, not producing a result is
> not the same as producing a table of
> zero rows by one or more columns. (This is like the distinction between
> the two comparisons
> "" == False
> and
> "" is False
> , the empty string has the same 'value' as False while remaining distinct.)
> I do not know that this will ever make a difference to my users
> but I am expected
> to be precise in my implementation. Is it the general understanding
> that .description
> will return None whenever the result set has no rows?
I can't speak for the universe, but that's not my understanding.
My interpretation of the spec is that "operations that do not return
rows" means non-DQL (i.e. DDL/DML/DCL) operations. DQL operations should
IMHO always be considered as returning rows, even if they happen to
return an empty set of rows.
Hence, .execute()ing a select statement should always set .description
to non-None, even if the result set happens to be empty. Making a
special case for empty selects is neither desirable nor, in general,
possible.
The special case is in general not possible because in many database
engines and their DB-API implementation, actual row retrieval is
deferred to the fetch methods, so .execute() wouldn't even know if any
rows will be returned. (This is true for e.g. InformixDB, but any
database engine that supports server-side cursors is likely to behave
this way.)
The special case is not desirable because there is at least one use case
for having .description set after executing an empty select, namely, the
cheapest way to inspect the names and types of the columns in a table:
cur.execute("select * from sometable where 1=0")
Just my two cents,
Carsten Haese.
http://informixdb.sourceforge.net
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
