[DB-SIG] DB-API Spec. 1.1a1

[M.-A. Lemburg]

Greg Stein (Exchange) wrote:
> 
> I don't believe there is really any need for new date/time handling at
> the database module level. One of the purposes of the DBI module was to
> handle this specific problem.

As Bill and Jim already pointed out, the current date/time
handling in Python is fine when all you care about is a range
from 1970 to 2038, but as soon as you want to handle dates
beyond that range, you get into trouble. And there are still
many around having been born earlier than 1970 ;-) Meaning that
whenever you plan to do serious DB work (which will sooner
or later deal with dates of birth), you cross the interface
in some other way (well, maybe you're lucky and the t_time
functions handle negative properly...). So a new date/time
handling mechanism is due anyway.

Of course, dbiDate should use this new type. As I understood
the dbi definitions, the classes dbiDate and dbiRaw are meant
as wrappers only -- for the sake of having type information
around. So dbiDate would only pass through the date object and
the DB interface can then make use of the C API for the new type
which certainly is much easier to program than having to deal
with 2 or 3 different formats, I agree.

> 1a) when a fetch is done, how do you differentiate a date from an
> integer or float? Using a tuple is possible here, but they are harder to
> work with than the integer/float (time_t) format. Instead, fetch returns
> an instance of dbi.dbiDate, with its "value" attribute set to an
> integer/float Python object.
> 
> 1b) when an insert is done, how do you differentiate a date from
> something else? Again, you could use a tuple, but you could then run
> into a problem differentiating between inserting multiple dates vs.
> inserting multiple rows of one date each. The answer is using
> dbi.dbiDate instances and extracting the value attribute.
> Note: in most databases, you must know the input binding type a priori
> before the binding occurs. That is why you need to know the type before
> inserting.
> 
> 2a) when a fetch is done, how do you diffentiate a string from a
> LONG/BLOB/whatever? Of course, representing those as a string is quite
> handy. This can go either way, but 2b (below) implies that you want to
> use a custom type: dbi.dbiRaw for these
> 
> 2b) when an insert is done, you need to diffentiate between a string and
> a LONG/BLOB. Here, you definitely can't use a string. The answer is to
> use dbi.dbiRaw and extract the value from it.
> 
> The mechanism of using custom types for dates and longs/blobs as
> indicators for insert (and partially for fetch) was solved by using the
> dbi module.

I don't have a problem with using the dbi module and do see
its relevance for those DBs which don't provide a describe API for
prepared executes, but in this special case I think we would all
benefit from having an extra type around -- not only for interfacing
to DBs, but also to implement other nifty things like e.g. financial
time calculations.

> I would recommend that if you want different date/time formats, that you
> simply implement new methods on the dbiDate instances. Better yet, just
> relegate that work to Python layers. Bill is quite on the mark when he
> says to avoid imposing extra work on database implementors. One single
> format is preferable.

IMHO, this should be a date object on both input and output.

> [ although, I'm not sure where the heck he was going with the date
> module concept since dbiDate represents the type that he's looking for.
> ]

For those interested on the date/time subject, I recommend
the calendar FAQ:

	http://www.pip.dknet.dk/~pip10160/calendar.html

BTW: I'm working on a prototype for a such date type in Python.
I'm not yet sure, but it seems that actually two types will emerge
from it: one for fixed points in time and one to express
time deltas.

-- 
Marc-Andre Lemburg


_______________
DB-SIG  - SIG on Tabular Databases in Python

send messages to: db-sig@python.org
administrivia to: db-sig-request@python.org
_______________