[DB-SIG] paramstyles, again

[Art Protin]

Dear folks,
    Carsten Haese wrote:

>On Fri, 2007-06-01 at 09:34 -0400, Art Protin wrote:
>  
>
>>First, I must confess.  I do not know how to make a module's
>>attributes read-only.
>>    
>>
>
>Um, apparently neither do I ;)
>  
>
Thank you!!

I needed this.  I laughed out loud to read your response.
A nice way to end the week.

>I just tried, and informixdb allows me to change its paramstyle
>attribute. Then again, there are no code paths in informixdb that depend
>on the paramstyle setting.
>
>  
>
>>Optional keyword arguments are a very good approach & I do like the
>>inheritance scheme.  Would it make sense for paramstyle to be an
>>attribute
>>of connection and cursor, that could be read and written?
>>    
>>
>
>I was kicking around that idea, but I discarded it because it violates
>the "Single Point Of Truth" principle. If the paramstyle of a cursor can
>be changed after the cursor is created, the execute calls on that cursor
>can in general not be sure that the paramstyle is still the one they
>need. Each execute call would then have to explicitly specify its
>paramstyle, which defeats the purpose of the inheritance mechanism.
>
>The problem is not as pronounced as the problem caused by allowing the
>user to set the module's paramstyle, because cursors are rarely if ever
>passed between threads, but a cursor object could conceivably be shared
>across functions.
>  
>
Yeah, I see the point.  Set the style on object creation and make the 
attribute
read-only.  Does it need to "pass through" the connection object or can the
cursor inherit its default from the module?


>  
>  
>
>>I would like autodetection, even prefer autodetection, if I was sure
>>that it would
>>work correctly every time no matter what.  I am getting more
>>comfortable with
>>that hypothesis, but have not yet developed a proof that autodetection
>>could not
>>get spoofed.
>>    
>>
>
>What do you mean by spoofing in this context? Making the parser think
>that the paramstyle is one thing when it is in reality something else? I
>think we can make spoofing impossible by definition.
>
>In order to spoof the auto-detection, you'd have to make the query
>contain both false positives (character sequences that aren't parameter
>markers but are recognized as parameter markers) and false negatives
>(parameter markers that aren't recognized as such). An adequate query
>parser MUST always recognize all parameter markers that are present,
>therefore a parser that permits false negatives is not adequate. [If the
>parser has to err due to performance reasons, it must err on the side of
>false positives.] Hence, an adequate parser can not be spoofed.
>
>Of course, I've simply transformed the problem to "Does an adequate
>parser exist for your SQL dialect?" but I think we'll just have to
>stipulate that the answer is yes.
>  
>
Ah, there is the disconnect.  For my interface I must ask can I code enough
of a parser for my dialect of SQL in Python so that my module can properly
handle parameters.  There is no reasonable way for my driver to get the
backend to parse the query and then tell the driver what parameters are
needed.  My driver must dissect the query enough to identify all the 
parameters
and "transform them" in the query before passing the query to the backend.


>Best regards,
>
>  
>
    Thank you all,
    Art Protin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/db-sig/attachments/20070601/3c1df820/attachment.html