[DB-SIG] Remaining issues with DB API 1.1

M.-A. Lemburg mal@lemburg.com
Sun, 28 Mar 1999 14:25:08 +0200


Greg Stein wrote:
> 
> 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.

Ok, they're in :-/

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

I wonder how they managed to get those dates of birth into the
databases (and even more important: back out of them ;-).

Never mind; I'll add the above constructors to the spec and
include the above source code as implementation hint.

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

Ok.

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