[DB-SIG] ctsybasemodule problem and dbi question

[Greg Stein]

M.-A. Lemburg wrote:
> ...
> Ok, I'm a little biased: ODBC let's you query the types of the
> to-be-bound parameters after statemente prepare and prior to
> the actual execute. Still, I think that these cases should be
> indicated by using (standard) Python types rather than reinventing
> the wheel for every database interface out there.

"should" ... but recall this was three years ago. The standard python
types for raw sequences of bytes were (are!) strings. Dates are
integers. The DBI types merely wrap these to provide additional info to
the modules, while the actual value is found in the "value" attribute.

Sure, as Python picks up new types, then things can change. Until then,
I believe the DBI style is appropriate. There shouldn't be N
copies/varieties of the module, however. That has been a mistake.

Does ODBC really allow you to query *input* bindings? Output bindings...
sure. But querying the types of the input would surprise me. Regardless,
Oracle barfs if you attempt to bind a string (in the Oracle sense) for
input, but it requires a LONG (RAW).

> So I guess appropriate approach would be replacing the dbi types
> with ones that are not only mere wrappers but provide useful
> functionality such as the mxDateTime types.
> 
> A proper raw type would be one useable as generic read/write buffer
> complying to the buffer interface.

These would be handy, and would be an improvement. Python 1.5.2 has a
buffer type built into it now, although there isn't a Python-level
constructor for it (yet). That may be an option for replacing dbiRaw.
Using mxDateTime would seem to be fine.

> For monetary types, a fixed decimal point format would be nice
> along with currency information to be able to implement automatic
> currency conversion.

Most databases allow binding of an integer/float against a currency
column. This wasn't been the case for dates and LONG columns, though, so
only those two had DBI types. I might argue that a currency type should
be relegated to Python, and leave the module simple.

> ...
> Or we could use a different approach: wrap the types up in a
> seperate distribution along with all kinds of useful documentation
> and maybe even precomiled binaries... then we could point people
> at one other package to download instead of giving them three or
> four different pointers.

This was the hope with the dbi module. If new, useful types replace
it... sure. I might suggest deferring this kind of change to a 1.2 spec.
I'm not really convinced that anything is broken, beyond the multiple
copies of dbi out there (and how the modules link/find dbi).

Cheers,
-g

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