<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1">
<TITLE>RE: [DB-SIG] date/time handling</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Mario Frasca wrote:<BR>
On 2006-0806 14:01:27, Robert Brewer wrote:<BR>
> > > but then also data *going* to the database must be<BR>
> > > clearly typed.<BR>
> ><BR>
> > Yes. The value-adaptation layer must be aware of the target column types.<BR>
><BR>
> I think that the value adaptation layer should not be aware<BR>
> of the target column types, it should, according to me,<BR>
> base every choice on local information, that is: the type<BR>
> of the incoming data, be it *from* the database (and the<BR>
> type information is present in most engines) or *to* the<BR>
> database (then the type information should be agreed on,<BR>
> that is what we are doing here). if the user sends a string,<BR>
> it will not be translated and the user is responsible for it<BR>
> being a valid string representation of the typed value<BR>
> to be stored in the column.<BR>
<BR>
Then you are adding zero value in the DB-API layer over what every Python DB wrapper already does. That works great until you write integration code for multiple legacy databases, where some dates are stored in ADO DBDATETIME, some are TEXT in "YYYYMMDD" format, and some are SQLite "typeless". Providing the DB-API adaptation layer with both the Python type and the database type can relieve the vast majority of that burden from the user. It works in Dejavu, and exists there in direct response to the limitations of the approach you describe (which Dejavu did previously).<BR>
<BR>
<BR>
Robert Brewer<BR>
System Architect<BR>
Amor Ministries<BR>
fumanchu@amor.org</FONT>
</P>
</BODY>
</HTML>