[DB-SIG] Towards a single parameter style

[Stuart Bishop]

On Saturday, February 22, 2003, at 02:31  PM, Anthony Tuininga wrote:

> 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)

Assuming these are methods on the Cursor object, are there any cases 
where
you would ever get a boost by explicitly calling prepare() before the 
execute?
	cur.prepare(my_sql)
	cur.execute(my_sql,args1)
	cur.execute(my_sql,args2)
would perform exactly the same as just
	cur.execute(my_sql,args1)
	cur.execute(my_sql,args2)

This prepared statement caching behaviour is already specified like this
in the DB-API, except that the prepare method is not exposed as there 
has been
no  need for it. The only rationale I have seen so far in this thread 
would be
to prefill the 'description' attribute (if the backend can actually do 
this
without executing a possibly very expensive query).

""" A reference to the operation will be retained by the
     cursor.  If the same operation object is passed in again,
     then the cursor can optimize its behavior.  This is most
     effective for algorithms where the same operation is used,
     but different parameters are bound to it (many times). """

-- 
Stuart Bishop <zen@shangri-la.dropbear.id.au>
http://shangri-la.dropbear.id.au/