[DB-SIG] paramstyles, again
mal at egenix.com
Mon Jun 4 15:32:05 CEST 2007
On 2007-06-04 13:17, Carsten Haese wrote:
> On Mon, 04 Jun 2007 10:41:46 +0200, M.-A. Lemburg wrote
>>> We still need to settle the question of what to do about numeric and
>>> named styles. There is some support for making both styles mandatory and
>>> expecting the API to automatically discern from the query string which
>>> parameter style is in use.
>> I don't think that this is such a good idea and I'm also not sure
>> how you'd do that: what if a programmer mixes the two (or three)
>> styles by mistake ? How would the programmer test whether a
>> module supports this automatic detection scheme ?
> If the programmer mixes incompatible parameter styles, the implementation can
> choose to handle it gracefully (sqlite3) or raise an exception (InformixDB).
> InformixDB actually allows mixing qmark and numeric in a straightforward way:
> The first question mark is equivalent to :1, the second question mark is
> equivalent to :2, etc. Only mixing positional markers and named markers raises
> an exception.
> I'd be okay with throwing an exception in any case of mixing, but I don't know
> how that would sit with sqlite3.
> The test for whether the module supports the automatic detection is
Do you really think it's reasonable to have the module parse
every single SQL statement just to detect the param style ?
What happens if you're in qmark style mode and the SQL statement
contains substrings which look like named style (but are not
intended that way, e.g. think stored procedures) ?
This approach also contradicts the explicit is better than
implicit Zen rule.
Just so that there's no misunderstanding: you're free to implement
this sort of extension in your module(s), but making this
mandatory in the spec feels wrong.
I tend to view this whole discussion as a bit off the track:
In an API specification, you normally define one way which all
implementations have to follow, not multiple ways of doing the
same thing in slightly different ways.
>> There's also the problem of parameter type if we allow named
>> style. The parameters would then have to be dictionaries for
>> named and tuples for qmark/numeric. So you effectively change
>> the signature of the .execute() methods based on a parameter
>> which is not good style.
> I disagree. It's duck-typing.
Following you proposal to require auto-detection, this would mean
more than just duck-typing. You wouldn't know what type to expect
until you've parsed the SQL statement string - ie. when you're
already inside the .execute() method and passed the argument
That's a bit much too dynamic and too implicit for an interface
* +1 on making support one param style mandatory for all
* +1 on requiring an interface to adjust the param style on a
per connection or even per cursor basis, so that it's easy
to setup an implementation to the mandatory param style
(in case the module defaults to another param style for backwards
This interface would have to support at least the mandatory
* -1 on doing auto-detection of param styles at .execute()
call time based on parsing the SQL statement
Professional Python Services directly from the Source (#1, Jun 04 2007)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
More information about the DB-SIG