[DB-SIG] ctsybasemodule problem and dbi question

M.-A. Lemburg mal@lemburg.com
Mon, 01 Mar 1999 11:27:04 +0100


Greg Stein wrote:
> 
> Cameron Mellor wrote:
> >
> > From: M.-A. Lemburg <mal@lemburg.com>
> > >...
> > >I think dbi is not really needed anymore: The only two types I can
> > >think of where it has some use are date/time values (use mxDateTime
> > >for those) and RAW input values (don't know how important it is
> > >to be able to differentiate between plain strings and RAW input --
> > >plain Python strings work just fine for mxODBC in both modes).
> >
> > I thought they were there as placeholders: that is, you knew from the data
> > that it was "special" and needed appropriate handling. Anyway, I'll take a
> > closer look and see what I can find. I may end up using ctsybase anyway
> > (since I'm playing with Sybase at the moment) and I don't really want it
> > dumping core. :-/
> 
> The dbiRAW type is mostly for *input* binding rather than output. As I
> recall, the Oracle database requires you to bind LONG / LONG RAW columns
> differently than VARCHAR columns. The dbiRAW type allows the execute()
> method to use the appropriate binding mechanism -- based on the argument
> being a string or a dbiRAW object.
> 
> Note: at the time the Oracle code was written, there was no way for the
> execute() method to figure out the right way to bind the input. Maybe
> Oracle has provided a way to prepare an INSERT statement, check the
> implied input types, and then perform the bind. Somehow, I doubt it
> though.

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.

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.

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

> The dbiDATE type exists for a similar reason: there was no way for the
> DB modules to determine that a particular input was a date. Presuming
> that a standard type is established for time/date handling (such as
> mxDateTime), then the DB module can do the input binding properly.
> 
> A similar situation would arise for money types or other special column
> types. If the underlying database requires that a column must be bound
> in a special way for that type, then the DB module must figure that out
> from the type of the arguments (since it has nowhere else to turn to for
> the info).
> 
> Marc: did I see somewhere that Guido might incorporate mxDateTime as a
> standard module in 1.6 or something like that?

That might be a possibility, but it's up to Guido to decide on that.
Inclusion of the above two types would then also be a good idea
(monetary
and buffer type).

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.

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