Database connect / PDO

[M.-A. Lemburg]

Jon Franz wrote:
>>mxODBC provides all .description values except display_size and
>>internal_size (and this is allowed by the DB API standard). These
>>two values are rarely of importance and if you absolutely need them
>>they can also be queried using the catalog methods the mxODBC exposes.
> 
> Sorry, but I disagree - these two values can be very important.

Can you present a use case ? display_size is predefined statically in
ODBC:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odappdpr_28.asp

I can't think of any use case for internal size...

>>You should note however, that some ODBC database drivers try
>>to be smart and "optimize" the return values that you see
>>in .description (the MyODBC driver is a prominent example).
>>While this is allowed by the ODBC standard, it is certainly
>>not good practice.
>>
>>As a result, the only true source of the schema information
>>are the catalog methods, e.g. .columns() available in mxODBC.
>>These also provide much more information than is available in
>>.description.
> 
> I can understand where you are coming from in that the drivers
> themselves may make it impossible to provide full/accurate column
> data from a query.  I'd wager you can't even automate calls to
> .column() because mxODBC doesn't necessarily know what table
> a column came from when results are fetched.

Well, the display_size could be hard-coded, but I don't
see much a use... internal_size would be hard to figure out
and is not worth the performance it costs. APIs like .gettypeinf()
and  .getinfo() can help you here, if you need more low-level
information.

> I can only speak for myself, but it is quite frustrating to not get
> the information I need when I perform a query.  Please realize
> that my message was not intended as a defacement or argument
> against mxODBC - I was simply warning the user of the pitfalls they
> may experience when using it with PDO.
> 
>>mxODBC 2.0.x is 100% DB API 2.0 compliant.
> 
> Then you should change your documentation :)
> "The mxODBC package provides a nearly 100% Python Database API 2.0 compliant
> interface "
>>From http://www.egenix.com/files/python/mxODBC.html

Good catch :-) I'll fix that. It was true for mxODBC 1.x.

>>The only omissions are .nextset() and .callproc() which will be
>>available in mxODBC 2.1.0. Both are optional in the DB API 2.0
>>specification.
> 
> 
> If this is why the documentation says nearly, then your interpretation
> of what 100% would mean is different from mine.  100% compliant
> would, in my mind, be supporting all required interfaces.  I wouldn't
> think optional interfaces are needed for compliance, and supporting
> them, although good, wouldn't come into the percentage... unless you
> wanted to say you were 105% compliant :)    .Just my two cents.

Hmm, I am the editor of the DB API 2.0 spec...

A database package can be 100% compliant without implementing
all optional features. The DB API spec was designed to allow
this since otherwise some modules would never be able to
call themselves compatible.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Nov 24 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::