[DB-SIG] Fetch_raw

[M.-A. Lemburg]

On 2007-05-02 14:47, Art Protin wrote:
> Dear folks,
>     I am considering yet another extension to my driver.  I especially
> like the way that the methods cursor.fetch...() return lists of objects
> of the right type and the user of the API (the application) does not
> need separate methods, one for each type, to fetch individual columns.
> However, in the debugging of our JDBC driver I find that there is
> some merit in getting the data, any of the data, as strings, which just
> happens to be the format that our database uses to pass them.
> Thus, there are two aspects where you could now influence my
> implementation:
> 
> 1) any of you could argue that it is a corruption of the API that will
> lead to bad results or bad practices to include a mechanism for accessing
> the "raw" data;  OR
> 2) any of you could argue about the form that such an extension should
> take.
> 
>     I am torn between adding an additional optional parameter to the
> methods .fetchone(), .fetchmany(), and .fetchall(),  and adding three
> new methods: .fetch_one_raw(), .fetch_many_raw() and .fetch_all_raw().
> (All of the names I used for extension methods and attributes have an
> internal underbar so my users will be able to easily tell that they are
> extensions.)  In the first case, the optional new parameter would
> indicate whether the data should be passed back normal or "raw",
> ie. with all the columns forced to be of type "string".  In the
> second case that information would be coded into the choice of method. 
>     I feel that even having the three methods, fetchone(), fetchmany(), and
> fetchall(), is too many (and too like JDBC) and would have written the
> spec (PEP 249) to have just fetch() with (an) argument(s) for the count
> (and any other needed parameters) to adjust the behavior.  However,
> now that the spec calls for three, should I follow that pattern and go on
> to providing six or buck it by adding an optional parameter to each of the
> three?

Why don't you simply add a configuration parameter to the
connection/cursor that sets the type mapping for all data
types to strings ?!

That way you avoid having to change your other code completely.

BTW, I still have to follow up to the type registry discussion.
Sorry, but I simply didn't have time to read everything yet.

Cheers,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 02 2007)
>>> Python/Zope Consulting and Support ...        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,MacOSX 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