[DB-SIG] Controlling return types for DB APIs
unixdude at gmail.com
Sun Apr 22 21:03:34 CEST 2007
(Resend since I hit reply instead or reply-all)
Wow, I'm really glad to see this topic has garnered such great
response from everyone. This make me really hopeful that we
can solve this issue.
On 4/20/07, Anthony Tuininga <anthony.tuininga at gmail.com> wrote:
> I've been following this thread and it would appear that no real
> consensus has been reached as of yet. I've looked at the api used by
> sqlite and knowing its storage and type definition system it makes
> good sense. I am considering adding the following to cx_Oracle,
> following some of the examples given so far with modifications needed
> for Oracle, and I'd appreciate any input you might have.
> cursor.setdefaulttype(databaseType, type)
> connection.setdefaulttype(databaseType, type)
I like the sounds of this. What are you thinking the databaseType
parameter? I can see using the standard database types that the
modules expose (STRING, BINARY, NUMBER, DATETIME,
and ROWID) along with extended types that are custom to the
database API. If the extended types were derived from the
standard types, then a bit of code that was portable could use
STRING to say that all strings map to Unicode or whatever, and
code that used an advanced feature of a database could map
NVARCHAR to Unicode and map VARCHAR to non-Unicode.
registeradapter(type, databaseType, fromPythonMethod, toPythonMethod)
> This would specify that whenver an object of the given type is bound
> to a cursor, that the fromPythonMethod method would be invoked with
> the value and would expect a return value that can be directly bound
> to the databaseType. The toPythonMethod method would be invoked when
> columns are retrieved and would accept the databaseType value and
> expect back a value of the given type.
Is this mapped as a tuple of type and databaseType? Or is this mapping
saying that to get to/from type you used the database type on the db side
and the correct function based on direction?
Some help on the names would be appreciated as well -- its the worst
> part of programming. :-) I've tried to use the DB API style of naming
> -- all lower case without any underscores even though it isn't my
> personal favorite.
I kind of like Robert's suggestions below about using an exposed
mapping object and being explicit about the direction of the conversion.
So I would suggest names like "defaulttypefromdb" and "defaulttypetodb"
(again using the existing db api naming style)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the DB-SIG