[DB-SIG] Remaining issues with DB API 1.1
Greg Stein
gstein@lyra.org
Sun, 28 Mar 1999 06:11:07 -0800
M.-A. Lemburg wrote:
>
> Greg: Are there going to be generic conversion C APIs for buffer types
> in 1.5.2 ? And is there some resource I could point to for more
> documentation on the types and their usage ?
Some alternatives:
1) str = PyObject_Str(buf);
2) use buf->ob_type->tp_as_buffer-> ...
The former creates a new string object based on the buffer contents. The
latter provides direct access to the contents without allocating
additional memory. The tp_as_buffer stuff is not documented (beyond "the
code is the spec/doc").
The buffer() builtin function is documented.
Your meta-comment about the lack of "Abstract Functions" is well-taken,
though. There are abstract functions for most of the type slots in an
object. However: this was done because if you're operating against a
class instance, then it would need to invoke a method rather than use a
type slot. There are no equivalent methods for the buffer interface, so
the need for abstract functions is arguable. The functions would merely
save you a bit of typing, rather than encapsulate any real
functionality.
> I'm asking this because I the current CVS version of Python 1.5.2
> doesn't have to much docs about the types and seems to be missing
> a way to extract information out of the buffer types other than
> going through PyArg_ParseTuple().
That is a slow way to do it. People should use the tp_as_buffer slots'
functions. For example, you could bind right against the address
returned using the getreadbuffer type slot function.
Interesting note: memory-mapped files export the buffer interface. You
could mmap a file and then start shoving the bytes into a database by
passing the file as a column value. hehe...
> Another issue:
>
> How should we define the mapping of Unix ticks to date/time/timestamp
> values ? ... or should we define them at all ?
IMO, that is module-dependent. A ticks value specifies a distinct point
in time. If a database is interacting with a column type which has less
precision, then some kind of truncation will occur in a
database-dependent fashion.
Part of my pushback against the three varieties is that they attempt to
provide coverage, when that really isn't the case. For example, MySQL
and Informix allow you to specify DATE columns with near-arbitrary
precision. Want just a year? No problem. How about a year and a month?
Sure. Just an hour and minute? Yup.
Providing a generic "type" of column called a "DATE" can encompass all
these varieties. Subtypes (per the scheme you posted which uses __cmp__)
can refine the generic type down to whatever precision or subtype is
required.
> Since ticks always refer to timestamp like values, converting them
> to date and time values will have to cause some kind of factoring.
> In the examples I gave, local time broken down values are used
> as basis. This could, of course, also be done using GM time.
Historically, the ticks value was broken into specific parts using
localtime() or its C equivalent. (and mktime() on the other side)
If a module implementor is using a sophisticated datatype like
mxDateTime, then they don't need to worry... it will Do The Right Thing.
For those who don't use it, they'll have a small paragraph of C code to
write.
> I've update the spec to 1.1a12.
Cool. I should get to updating the annotated version. It is woefully
behind.
> The next release of mxDateTime
> will include the new constructors for ticks based values.
I thought it already had that. I looked thru the spec the other day. Or
did it only have *output*, rather than constructors?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/