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

[Richard Taylor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 06 June 2002 3:26 pm, Matthew T. Kromer wrote:
>>[...]
> 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.
>

- From a humble DB API users perspective having the fetch functions return a 
zero-length return set would be fine. It would enable sensible code where an 
"exception" meant just that and no DB specific code would be required.

> >[...]
>
> 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.
>

I can see your point. I would only argue for a specific exception for "no more 
records" if your option of a zero length result set was not taken up. Mapping 
real exceptions onto a DB-API subset would be a bad idea. 

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

Indeed, although this distinction would be lost by a zero length result 
approach.

>
> 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.
>

I have no problem with not knowing how many results rows there are, all I want 
is a portable way of know whether there are any results rows and I don't mind 
calling fetch to find out. 

>
> 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.

I think you are absolutely right about passing on the underlying database 
errors. All you can usually do with unexpected exceptions is log them 
somewhere and try to recover. It then becomes very important that what is 
logged in useful and only the root DB error information is going to help with 
debugging.

I also agree that DB dependant functionality should be allow and expected. 
Indeed we make use of Postgres specific functionality ourselves. However, the 
simple action of making a query and fetching the results seams to me to be so 
fundamental to every application that it should be portable.

What is the opposition to the zero return set option?

Richard

- -- 
QinetiQ                                  
B105 Woodward Building
St. Andrews Road
Malvern
Worcs WR14 3PS

The Information contained in this E-Mail and any subsequent correspondence
 is private and is intended solely for the intended recipient(s).
 For those other than the recipient any disclosure, copying, distribution, 
or any action taken or omitted to be taken in reliance on such information is
 prohibited and may be unlawful.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8/3gA7Z7YaKfan9kRAvPPAJ40hImIMGpikpJJuN+S7cEXpiUvpACeKi4w
eNoXcF+EZuCwQUlwsBgqxRM=
=g26A
-----END PGP SIGNATURE-----