[DB-SIG] checking column types from cursor object in a database-independent way?

[M.-A. Lemburg]

On 23.04.2013 17:00, Daniel Lenski wrote:
> On Tue, Apr 23, 2013 at 12:29 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>>
>> I don't think we should clutter up the connection objects with
>> module scope attributes that hardly ever get used.
>>
>> The exceptions are used a lot, so it makes sense to have them
>> easily available via the connection object - even though I'm not
>> sure whether that particular DB-API extension was such a
>> good idea w/r to API design (it's one of those practicality beats
>> purity things).
> 
> Again, I understand the desire not to cruft up the cursor or
> connection namespaces, but I am sort of surprised that you consider
> the type objects to be little-used. It seems to me that they are a
> necessity for any abstract DB-independent layer.

Database data type handling is very complex and in practice you
need to deal with a whole lot of issues that the high level
DB-API type objects don't capture, e.g. supported data ranges,
encoding support, precision, etc.

Today's databases also often support additional types for e.g.
geo location, network addresses, XML, ranges, etc. for which
there's no corresponding DB-API type.

See http://www.postgresql.org/docs/9.2/static/datatype.html for
a typical example of what databases provide today.

Such logic is better left to higher-level database abstractions,
which then support a handful of backends. I'd be +0 on
deprecating the type objects for DB-API 3.0. While they don't
introduce a lot of overhead for database module authors, they
aren't all that helpful to users and can lead to confusion.

>> Adding access to the database module via the connection object
>> would allow to resolve all this. The problem
>> with doing so is that you typically don't want the module
>> object to be referenced directly by hundreds of objects in your
>> application and you can also run into problems when reloading
>> modules or (depending on how this is implemented) circular
>> references.
>>
>> A method doing the lookup via the sys.modules dictionary
>> could resolve those issues:
>>
>> database = connection.database()
>> try:
>>     cursor = connection.cursor()
>>     cursor.execute(...)
>> except database.DataError:
>>     ...
>>
>> Thoughts ?
> 
> This seems like a reasonable solution to me, that would solve both
> this problem as well as similar ones.
> 
> Alternatively, a cursor.coltypes attribute (in term containing
> .STRING, .DATETIME, etc.) would solve the present problem.
> 
> Dan
> _______________________________________________
> DB-SIG maillist  -  DB-SIG at python.org
> http://mail.python.org/mailman/listinfo/db-sig
> 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 02 2013)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2013-04-30: Released eGenix PyRun 1.2.0 ...       http://egenix.com/go44

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/