[DB-SIG] ANN: mxODBC Version 0.3

[M.-A. Lemburg]

Jim Fulton wrote:
> 
> Bill Tutt wrote:
> >
> > in DBI, and DBI is a useful abstraction mechanism, and is database
> > independant..
> > Why does it need to be tossed?
> 
> I think people may want to toss it because the existing
> module is not well documented and a bit painful to use.  This
> can be fixed, of course.
> 
> As has been pointed out, there are several dbi modules around.
> I had to modify the version that I distributed with oracledb
> to make it non-windows non-C++ specific.
> 
> More importantly, the current versions of the dbi module
> are dynamic-linking unfriendly, especially on non-windows
> platforms.  The dbi module should be modified to use the
> CObject machinery to export it's C interface to other modules.

Why does it have to be a C module ? I wrote it up as Python
module and it works just fine. All the technical stuff is
imported from the DB module.

> > Dates:
> > Well there isn't any difference between what you do, and what
> > the DBI/Win32 ODBC code does.
> > (Well except for handling TIME types but thats just a function of
>    ignoring the date part, or indeed just one line in odbc.cpp)
> > They're both limited to dates after Jan 1, 1970 00:00:00 GMT.
> > What we should do is come up with a sane date type for Python
> > that isn't
> > based on time_t.
> 
> Absolutely. I made some noise about this about a year and a half ago.
> The discussion was going in a direction that I could not contribute to
> at the time. Since then, I've come around to a position that
> is closer to many of the positions advocated at the time.  I think
> there is a more-or-less-standard Date/Time model for many databases.
> 
> The Spec I'm familiar with is the ODMG-93 spec that includes Date,
> Time, and TimeStamp.  I suspect that these are based on some
> wider standards, and there are similar looking structs in the
> ODBC interface (sql.h).

Here is what I propose (which comes pretty close to what you find
in sql.h):

IMO, the easiest way to support the whole range of possible dates
under SQL, is to pass:

	timestamps as (year,month,day,hour,minute,second,millisecond)
	dates as (year,month,day)
	times as (hour,minute,second)

as *alternative* to the time value (seconds since epoch). Any
string representation would conflict with either the
databases current date format settings or the current locale.
The version to be used could be set by a

	cursor.setdatetimeformat(x)

method, where x == 0: cursor returns/expects time values as before and
	      x == 1:  -"-                   tuple values as above

The corrseponding

	cursor.getdatetimeformat()

method would return the current value.

Something else:

I have silently updated the mxODBC to version 0.4. It now
comes with a dbi-module due to popular demand and also raises the
exceptions that Bill mentioned in his recent post. The ODBC catalog
functions were already added in 0.3. I also changed the way warnings
are returned: up until 0.3 they were silently ignored. Now they result
in a noError exception (I consider truncation of data severe enough
to give note to the programmer). Though I don't consider "noError"
a particularly good name for a "Warning". This is taken from
the dbi-module that comes with mxODBC:

error = mxODBC.error
dataError = mxODBC.DataError
integrityError = mxODBC.IntegrityError
internalError = mxODBC.InternalError
noError = mxODBC.Warning
opError = mxODBC.OperationalError
progError = mxODBC.ProgrammingError

Maybe there's still a chance to have some discussion on the names ?

The next version of mxODBC will probably also include the above
alternatives for date/time formats.

	http://starship.skyport.net/~lemburg/mxODBC.html

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