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 _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
