[DB-SIG] paramstyles, again

[Art Protin]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/db-sig/attachments/20070522/55f12a69/attachment.html