[DB-SIG] Towards a single parameter style

[Anthony Tuininga]

So, if there is one common module, it can have a paramstyle as writeable
attribute to allow for a smooth transition, or it can be set for each
"plug-in" (low level driver) for a smoother transition.

On Mon, 2003-02-17 at 03:46, Dittmar, Daniel wrote:
> > The "single parameter style" idea is really one where the programmer
> > only has a single option and the module takes care of the translation.
> 
> Agreed.
> 
> > Now this would be hard to agree on and it will also break existing
> > code, so I think we should just make the preferred paramstyle
> > a suggestion in the DB-API. I'd vote for the simplest of them
> > all: the 'qmark' style.
> 
> My proposol  tried to achieve just that:
> - doesn't break existing code
> - allows to use the standard parameter style with just one additional statement when creating the connection
> 
> I don't want choice, but ease of transition.
> 
> > Eek. No. Please don't try to introduce paramstyles per cursor,
> 
> I'd rather introduce them per connection. But having them per cursor allows to rewrite an applicationm method by method (provided cursors are used locally).
> 
> > that's bound to cause endless problems -- you'll end up having
> > to deal with 5 different param styles in complex applications
> > where each programmer starts using its own preferred style. Even
> 
> Certainly not the only way lack of discipline can foul up a Python program.
> 
> > worse, you'd have to switch the applications paramstyle depending
> > on the cursor you get.
> 
> Maybe I have the wrong idea on how cursors are used. I would think the actual execute happens mostly in one place, unless you use a global cursor for everything.
> 
> I use them either as PreparedStatements or ResultSets (JDBC speak), so my view may be a bit limited.
> 
> If cursors are used in other ways, then I agree that the whole application has to be changed in one step.
> 
> > If modules want to support multiple paramstyles, they should implement
> > this in the .executexxx() methods using a new optional parameter
> > paramstyle. This makes the choice local to where the SQL gets passed
> > into the interface, so the above concerns should not apply (unless
> > I'm mistaken).
> 
> I would assume that the new standard paramstyle is introduced as an addon first because of backwards compatibility. This would mean than the program written to the standard will be the wordiest. Additionally, if I have a program that already uses the standard param style, I'd still have to add all those paramstyle = 'whatever' to make it portable.
> 
> Daniel Dittmar
-- 
Anthony Tuininga <anthony@computronix.com>