Dear folks,
Carl Karsten wrote:
Carsten Haese wrote:
On Mon, 2007-05-21 at 16:46 -0500, Carl Karsten wrote:
I have been following this on and off. I don't have much to add to the specific
problem, but I do have some general thoughts that may help.
I.
It seems to be a similar (not same, and even similar may be a stretch) problem
to the parameter formating problem 'solved' by .paramstyle which is one of the
worst solutions I have seen to any problem :) to me, the parameter problem
should be solved "in" the db-api layer, not above it (assuming application is
above database.) Again, I agree that the type problem is not the same as
parameter, so it may need a different solution that will have similarities to
what I dislike about .paramstyle.
I'm not sure exactly what you mean here. paramstyle fulfills its
function of giving the API implementor enough freedom to get the job
done and letting the application developer know which option the
implementor chose. Now, IMHO format and pyformat paramstyles are an
abomination that should disappear from future versions of DB-API, and
qmark should be the mandatory minimum, but I digress.
to me it gave the API implementor too much freedom for no good reason, other
than make it easier by making it the application developers problem. I don't
see why one format couldn't have been chosen and all API implementors could work
with it, just like all application developers now have to work with it.
Initially I also saw the .paramstyle as providing the implementor too
much freedom.
However, I chose to take it as a challenge. In my implementation,
.paramstyle is not
read-only but read-write and all of the defined styles are accepted. In
fact, once I
figured out how to handle the parsing of SQL comments & literals,
parsing of any
style of parameters was almost trivial (I had to do that parsing in
Python due to the
nature of our system). [Actually, I had to add code to block the styles
"pyformat"
and "format" because my boss agreed with Carsten, although he would have
preferred
that I removed code.]
In my opinion (which is never as humble as it should be), "qmark" is
barely adequate;
numeric should be the required minimum. But now that so many have
gotten used
to "qmark", it will probably never go away.
I am glad that the spec. [PEP 249] did not require that .paramstyle be
read-only and
now oppose any attempt to "correct" that oversight.
My outputmap/inputmap proposal is built with flexibility in mind. Maybe
that's what's bothering you, I don't know.
II. (going out on a limb here...)
A user defined data type is used (therefor defined) by the application, so it
makes perfect sense that the app layer would have implementation details. If
the person defining the datatype wants to use it across applications, then they
will code an appropriate class. I can't see how a user defined anything can be
handled generically.
Of course. Informix Dynamic Server allows user-defined types, which is
precisely why my outputmap/inputmap mechanism is flexible enough to
handle a lot of different use case scenarios. But it also provides a
foundation for handling common use cases with standard typemaps that
have database-independent names and agreed-upon semantics.
That sounds in line with my thoughts.
Carl K
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
Thank you all,
Art Protin
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
