[DB-SIG] Controlling return types for DB APIs

[Jim Patterson]

On 5/7/07, Carsten Haese <carsten at uniqsys.com> wrote:
>
> On Mon, 2007-05-07 at 09:53 -0400, Art Protin wrote:


In general I like the proposal.  I think it will go a long way to
make it easier to write adapter specific logic to handle data
conversions.  However, I wonder how much it helps the
issue of writing adapter neutral code.  For these conversion
functions to work, the adapter needs to call the function passing
some data of some sort.  That would seem to be database
specific.  I know that Oracle for example uses a custom
format for numbers in it's API, and I have never seen any
other database use the same format.  cx_Oracle hides this
from the python universe and returns floats or strings (and
maybe Decimal in the near future), but it has to be told
which one to use.

Strings are just as much of an issue.  It is database specific
how the strings are encoded in it's internal API, it could be
ASCII, or UTF-8, or UCS-2 or ...

How did you see that working?

In my scenario, the application developer would provide (or reuse
> previously provided) database-specific adapter functions to map the
> database-specific object into a database-agnostic application-side
> object and back, and plug the appropriate functions into the
> outputmap/inputmap of the corresponding database connection. The
> adapters would be database specific, but the API for registering the
> adapters would be the same across all compliant databases.
>
> [1] For those that are new to this thread, see
> http://www.uniqsys.com/~carsten/typemap.html .


If we want to address the problem for the common cases
like strings, dates, and numbers then we need to extend
your proposal to require the database api to provide the
typemappings for the common cases.  If we leave
those mappings optional and don't specify the name
of the supplied mappings then code will still be adapter
specific.

The pre-established semantics disagree. I think it's better to stick to
> those semantics than to confuse matters by adding another naming
> convention such as import/export or fromdb/todb or fromapp/toapp.
>

I agree.

Jim P.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/db-sig/attachments/20070509/3e08ee3c/attachment.htm