[DB-SIG] Remaining issues with DB API 1.1

[M.-A. Lemburg]

Andy Dustman wrote:
> 
> On Fri, 26 Mar 1999, M.-A. Lemburg wrote:
> 
> >        · Require a constructor to take Unix ticks as input for timestamp
> >          values ? What about time (without date part) and date (without
> >          time part) values ?
> >
> > Well, you know my POV: ticks are a bad thing for serious DB interfacing
> > and there are ways to convert them to the broken down values needed for
> > the constructors.
> 
> OTOH, ticks are pretty ubiquitous. Supplying a constructor that uses them
> isn't a big deal; mxDateTime has one, right? Certainly it should not be
> the only constructor, but available as an alternative.

Sure, mxDateTime has constructors that take ticks as argument and
there is also a generic solution:

def DateFromTicks(ticks):

    return apply(Date,time.localtime(ticks)[:3])

def TimeFromTicks(ticks):

    return apply(Time,time.localtime(ticks)[3:6])

def TimestampFromTicks(ticks):

    return apply(Timestamp,time.localtime(ticks)[:6])

Still, I think we should not put any emphasis on using them for
database interfacing by requiring the above constructors in the
spec. A module implementor is always free to provide the constructors
and a user can supply them herself in case she wants to use ticks.

> I'm agreeable to everything else. I would help on the spelling/grammar but
> I will probably be spending this weekend working on a Python intro for the
> local ACM chapter that I'm presenting on tuesday.

Ok.

Another issue that I've overlooked previously...

The 1.0 API spec for the fetchmany() method is:

fetchmany([size]) 
         Fetch the next set of rows of a query result, returning as a list of
         tuples. An empty list is returned when no more rows are
         available. The number of rows to fetch is specified by the
         parameter. If it is None, then the cursor's arraysize determines
         the number of rows to be fetched.

That last part is bogus, IMHO. Also, the spec does not state how
many rows to fetch if size is completely omitted. How about specifying
size as optional argument that defaults to cursor.arraysize ?! ...

fetchmany([size=cursor.arraysize]) 
         Fetch the next set of rows of a query result, returning as a list of
         tuples. An empty list is returned when no more rows are
         available. The number of rows to fetch is specified by the
         parameter. If it is not given, the cursor's arraysize determines
         the number of rows to be fetched.

A similar change should be done for setoutputsize(size[,col]) w/r to
the col argument.

I've updated the spec according the above lines (which, of course,
doesn't mean you can't object ;-) :

	http://starship.skyport.net/~lemburg/DatabaseAPI-1.1.html

I've also updated all the references to tuples/lists to sequences
and mappings for maximum flexibility. Tell me what you think about
it (BTW, Jim Fulton's result objects should now fit in nicely
with this spec).

Cheers,
-- 
Marc-Andre Lemburg                               Y2000: 279 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------