[DB-SIG] Last round for DB API 1.1

[Greg Stein]

M.-A. Lemburg wrote:
> ...
> > > · We still need to settle the sequence of sequence problem
> > >   with .execute().
> > >
> > > Since e.g. ('abc',) fits this definition but surely isn't intended,
> > > we'll need some other way to handle sequences of parameter/data
> > > sequences. How about depreciating the use of those lists in
> > > .execute() and defining a .executemany() method for this purpose
> > > instead ? Other ideas ?
> >
> > Right now it says "tuple or list of tuples". I'm happy with that.
> 
> Greg's not and he's got a point there. I am basically in favor of
> "sequences of sequences" too; it's just that the ambiguity has to
> be solved somehow. ".executemany()" would sound much like
> ".fetchmany"...

Yes, the issue is a database module that returns a sophisticated
datatype from fetchmany() or fetchall(). That datatype *must* support
sequence-of-sequence behavior. We also want to allow that datatype to be
passed back to an executemany() call (for example, if you're copying
rows between databases).

>...
> BTW: I've noticed that MySQL support BLOBs but does not handle
> binary data in those BinaryLongOBjects... is that a bug in their ODBC
> driver or by design ? [would render the Binary() constructor meaningless
> I guess...]

MySQL does handle long binary data.

The Binary() constructor will be a no-op since MySQL doesn't need hints
to differentiate the input binding between a VARCHAR and a LONG (like
Oracle does).

Dates are very tricky in MySQL, however. dbiDate arose out of the need
to differentiate between an integer and a Unix ticks value. The database
would then prepare the appropriate input binding. A similar need would
still exist, so a MySQL database module would probably still require a
date type.

Note: this comes back to my point about Unix ticks. Marc: you said we
should try to get rid of them. Sorry, but that is going to be quite
difficult. Python's concept of a date is a Unix ticks value or a
9-tuple. We must have a constructor that accepts one of those things
(since we can't pass a bare integer as a date, and I don't think we want
to allow passing a 9-tuple to mean a date). Since most Python
installations deal with dates in these formats, we must cooperate.

Cheers,
-g

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