[DB-SIG] Remaining issues with DB API 1.1

[Greg Stein]

M.-A. Lemburg wrote:
> 
> 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.

Marc: two of the three people that have been participating in this
discussion have said that having a "ticks" constructor is important. I
think it is fair to say that you've been out-voted, and the constructor
should be added. Without it, everybody is going to need to replicate the
functions you list above.

Also, what if a module implementor *doesn't* have a fancy date object?
They may want to use ticks. It has worked for Python programmers for
eight years, and C programmers for almost 30.

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

yes, call it an original spec error. The change you propose is fine.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/