[DB-SIG] DB API 1.1a3

Peter Godman pgodman@halcyon.com
Wed, 1 Jul 1998 15:05:12 -0700 (PDT)


On Wed, 1 Jul 1998, Tod Olson wrote:

> >>>>> "M" == M -A Lemburg <mal@lemburg.com> writes:
> 
> M> Tod Olson wrote:
> >> 
> >> I notice that 1.1 no longer requires Connection objects to implement
> >> all Cursor object attributes and methods.  Any reason?  I would like
> >> the requirement to remain.
> 
> M> Is anybody using this ? I think it's a better idea to provide a
> M> dummy cursor object than having connection objects give access to
> M> cursor methods and attributes: it makes porting applications a lot
> M> easier. Database interfaces which do not really support cursors
> M> could raise an exception if more than one cursor is being created.
> M> But that's of course just my POV.
> 
> But what about databases where connections and cursors really are
> different?  That is, in Sybase you can submit SQL through either a
> connection or a cursor, and that implies some meaningful difference to
> the server.  Eg. some things are legal in a connection that aren't in
> a cursor (don't ask for specifics, but we just saw an example two days
> ago).
> 
> Of course if no other database does this sort of thing, it probably
> doesn't need to be reflected in the standard.

I feel it is important that it be in the standard, and would ask that if
we want to get rid of one of the two interfaces, why not make it the
cursor interface?  One can alway implement cursors using language
commands (and presumably many are done this way).  Since Sybase supports
library and language cursors, and they behave and perform in quite
different ways, I'm happy that both interfaces exist because it means that
both types of functionality can be provided in my Sybase module.  Language
cursors may still be created by the user at will through the connection
interface.  

Without the connection interface in Sybase there would be no way for the
user to express regular language commands, including language cursors (am
I right in thinking this?), and without the cursor interface, it would be
impossible to express library cursors, which are the only cursors which
may be opened on the output of a stored procedure. This is useful
functionality.  Does anyone know what the other big advantages of
client-side (library) cursors are?  Honestly I don't remember the rest ;-) 

Which brings me to another point... I'm really getting out of touch with
the database world now (it's been a whole six months).  I've mentioned it
before and had some responses, but now I think I really have to ask if
anyone would like to take over maintenance of the Sybase module I wrote
(still definitely not _the_ sybase module (plenty of competition for that
title ;-)).  I have no Sybase access still and not a lot of time, since
I'm wrapped up in my job, and things RealAudio/RealVideo related.

Well, to everyone out there, let me know if you're interested.  

Thanks,
Peter Godman




> 
> Tod A. Olson                        "How do you know I'm mad?" said Alice.
> ta-olson@uchicago.edu               "If you weren't mad, you wouldn't have
> The University of Chicago Library    come here," said the Cat.
> 
> _______________________________________________
> DB-SIG maillist  -  DB-SIG@python.org
> http://www.python.org/mailman/listinfo/db-sig
> 
>