[DB-SIG] Is there a better way of doing this?

[Matthew T. Kromer]

Richard Taylor wrote:

>[...]
>
>This appears to mean that if "rowcount == -1" you have to just go ahead and
>call one of the "fetch" functions and catch any exception that is raised.
>This is not too bad except that which exception is raised for "no rows to
>fetch" is not defined in the spec. The "fetch" functions are defined to raise
>a "subclass of Error" but that includes a number of errors that the DBI
>library can raise. There is no specific "no rows to fetch" exception. The
>only implementation I can see is to check the "value" field of the Error
>exception to determine if "no rows to fetch" was the cause of the exception
>or not.
>  
>

It seems to me fetch should actually return an empty set when it cannot 
fetch more records, and the application should check for a zero-length 
return set.   Arguably, I violate the DB 2.0 API spec by doing this in 
DCOracle2.
DCOracle2 also updates the rowcount as records are retrieved, but that 
also makes it arguably worse; any logic that performed its OWN count and 
compared that to the rowcount attribute would decide that all the 
results were present immediately.

>This is bad because the DBI does not specify the syntax of the "value" fields
>of the Error exception. In my experience each DBI implementation chooses its
>own which are often different (e.g popy used "No more results to fetch" but
>psycopg uses "no results to fetch"). The upshot of all of this is that I can
>not see how to write the following code in a way that will work across
>different DBI implementations.
>
>[...]
>

I am rather strongly opposed to trying to over-genericize error returns. 
 Oracle has an error code space of thousands of error messages. 
 Granted, only a few mean "no records available" but if the vendor 
doesn't categorize errors by type, it is not reasonable to expect the DB 
API driver to do so.  Granted, you're not arguing for that, but I've 
already stated that I think the way to handle "no more results" is to 
return a zero length result.


Note that "no more results" is also different from "no results generated."


Oracle is also one of those databases that doesn't tell you how many 
records are in a result set up front; you have to pull them all and 
count as you go.   Is that frustrating?  Yes, certainly.   But an 
application that retrieves all the records in order to count them will 
have done so explicitly; with the corresponding penalty in performance.


By the same token, this is why you cannot also expect the values of 
errors to be consistent -- the values should reflect what the underlying 
database returns, and not some intermediate interpretation by the 
adapter.  That's not a very good thing to hear from the application 
programmer's point of view; but as an adapter author, I'll assert that 
there are plenty of database dependant things you can do within the 
bounds of the API right now.  Look at the mess of how to determine 
parameter binding styles.  Applications are nominally expected to be 
able to adapt to about 5 different styles of parameter binding; it would 
be much easier if the adapter and the application could negotiate on the 
binding style.

-- 
Matt Kromer
Zope Corporation  http://www.zope.com/