Dear folks,
Carsten Haese wrote:
On Tue, 2007-05-22 at 09:22 -0400, Art Protin wrote:
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.
Making the module's paramstyle writable is an odd approach. If you have
one function that needs one style and another function that needs
another, each function will have to explicitly set the module-level
paramstyle attribute before executing the query, for fear that another
function might have changed it in the meantime. That faint screaming you
hear in the distance is thread-safety being thrown out the window.
I have not spent any time yet on supporting thread safety.
But I see that making .paramstyle writeable hurts there.
So,...
This seems like the lead in to suggesting that the API be extended to
separate
query specification from query execution. I currently have query objects
being created and handled transparently by the cursor objects. I suspect
that a better interface would allow the query object be explicitly created
and then paramstyle would be an attribute of the query that could be
controlled both explicitly and thread safely. (I use the query string as
key for looking up the query object so as be able to reuse the preparation
work required by each query.)
What additional benefits would a separate query class provide?
What liabilities would it create?
As an example of an alternative, InformixDB allows qmark, numeric, and
named parameters, and execute() recognizes on the fly which one you're
using. The paramstyle attribute only "advertises" numeric, because there
is no way to advertise all supported styles while remaining compliant
with the spec.
qmark may not be adequate in your opinion, but it has the advantage that
it's SQL standard, as far as I know. Hence, it's the parameter style
that's most likely to be a native parameter style in commercial SQL
implementations. If we made qmark mandatory, application developers
could rely on the fact that at least qmark style will be supported.
Allowing additional parameter styles, either recognized on the fly by
execute(), or given as a cursor attribute, or given as an optional
argument to execute(), should be encouraged, but not required.
This has been discussed before, but I'd like to re-cast a vote on this
for DB-API 3.0:
* Deprecate/disallow pyformat/format paramstyles.
I can not get my boss to adequately describe why he dislikes these
parameter styles.
Can you offer up a rationale to help me see a reason to eschew pyformat
and format?
* Make qmark the mandatory minimum paramstyle. Allowing additional
parameter styles (numeric and/or named) would be optional and
implementation specific.
How about raising the bar.
Make qmark, numeric, and named all required. It does not take much Python
code to adjust between them (to be able to implement any one in terms of any
other) . Then maybe SQL will be modivated to get to numeric. Why let them
bring us down to the least common denominator?
[Is this extreme enough?]
Best regards,
Thank you all,
Art Protin
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
