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?
Thank you all,
Arthur Protin
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
