[DB-SIG] Towards a single parameter style

[Anthony Tuininga]

On Fri, 2003-02-21 at 16:40, Federico Di Gregorio wrote:
> Il ven, 2003-02-21 alle 15:54, Anthony Tuininga ha scritto:
> [snip]
> > Whether or not the prepare method is visible (it is very convenient
> > though if it is), the prepare step takes place internally and can be
> > skipped if the same statement (or None) is passed through to the
> > execute() method, thus improving performance. And the performance gain
> > here is considerable, even for Oracle where a second prepare is not as
> > costly as in some other environments. I have noted about 30-40%
> > performance improvements for heavy use of prepared cursors.
> 
> i agree. 
> 
> > One word: performance. If performance isn't a big deal, then neither
> is
> > prepared cursors. If you need other reasons: convenience is a big one.
> > And we all know how lazy we programmers are, eh? :-)
> 
> my objection is not to prepare itself. it is to include an explicit
> optimization usefull only to a handfull of backends. implement it as
> usefull extension to the dbapi, but don't require it to be implemented
> by every driver.

True. But if there were a common module, there wouldn't be a problem
with "implementing" prepare as a common __optional__ part of the API.
There is nothing inherently wrong with

def prepare(self, statement):
    if rawCursor.hasattr("prepare"):
        rawCursor.prepare(statement)
    self.statement = statement

def execute(self, statement, args):
    if self.statement is not None and self.statement is not statement:
        self.prepare(statement)
    rawCursor.execute(self.statement, args)

That would allow driver authors to completely ignore it if it has no
relevance to the database and implement it if it has performance
considerations. I'm not sure of the ratio of database systems that
support a "prepare" concept to those that don't, though.

-- 
Anthony Tuininga <anthony@computronix.com>