<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Anthony Tuininga wrote:
<blockquote
 cite="mid703ae56b0704200931m3a5e0048xe766eed8db8d70d3@mail.gmail.com"
 type="cite">
  <pre wrap="">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)

What this method would do is specify that whenever an item that is
represented on the database by the given database type is to be
retrieved, the specified type should be used instead of the default.
This would allow for a global or local specification that numbers are
to be returned as strings or decimal.Decimal objects or that strings
are to be returned as unicode objects, for example.

cursor.settype(position, type)

This would allow specification of the type to use for a particular
column being fetched.

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.

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.

Any comments?</pre>
</blockquote>
<br>
My initial reaction is that I like it! I like registeradapter() and
that it is easy to set at the connection or cursor level. <br>
<br>
I'm guessing that the cursor.settype() call is for a result set only
and that the adapter would be reset on a new cursor.execute() call?<br>
<br>
I'm also wondering if setdefaulttype() should have param 2 as an
optional param (i.e. if there is only one registered adapter the driver
can work out the 2nd param).<br>
<br>
It is probably worth defining a conflict resolution approach, even if
the approach is in documentation and says, "the behavior of conflicting
types in adapters is undefined"! E.g. sending to db conflict (note
fairly artificial):<br>
<br>
<blockquote><tt>registeradapter(str, DECIMAL, pyStr2dbDec, dbDec2pyStr)<br>
registeradapter(str, SPATIAL, pyStr2dbSpa, dbSpa2pyStr)<br>
cursor.setdefaulttype(DECIMAL, str)<br>
cursor.setdefaulttype(SPATIAL, str)<br>
cursor.execute('select x from mytable where mytable.col1 = ?',
('12.34',))<br>
## is the input supposed to be decimal or a spatial type?</tt><br>
</blockquote>
<br>
The alternatives are:<br>
<br>
<ol>
  <li>for the database driver to do some sort of DESCRIBE INPUT and
work out which adapter to use<br>
  </li>
  <li>to raise an error when registeradapter() is called with
conflicting types<br>
  </li>
</ol>
Any comments? Should this be driver dependent?<br>
<br>
<br>
As for names, I've a few suggestions but I don't feel strongly about
the names:<br>
<br>
<blockquote><tt>setdefaulttype --&gt; coercetype<br>
settype --&gt; coercecolumn</tt><br>
</blockquote>
<br>
registeradapter() is clear, I wondered about setadapter() instead, but
registeradapter() is probably the most clear.<br>
<br>
Chris<br>
<br>
</body>
</html>