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
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
