On 5/7/07, Carsten Haese <[EMAIL PROTECTED]> 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.
_______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
