[DB-SIG] Preparing statement API

[Greg Stein]

On 27 Jan 2000, Hrvoje Niksic wrote:
> "M.-A. Lemburg" <mal@lemburg.com> writes:
> > > This was the specific intent behind the current design. An
> > > unsophisticated provider (or database) need not worrying about
> > > caching, reuse, preparation, or implementing additional
> > > methods. The provider can add the reuse functionality and
> > > performance will increase.
> 
> That's good design, and I tried to preserve it.  As I said, an
> unsophisticated database can implement cursor.prepare() as
> lambda x: x.  What you cannot do with the current API is have control
> over whether a statement is cached.

And in your change, you *still* do not have that control.

If the DBAPI provide does not want to write that much code, for whatever
reason, then they won't write it. Adding a prepare() is not going to
magically force them to do anything other than a lambda x: x. You're
fooling yourself if you think otherwise.

> > Therefore, I propose to add the new features I mentioned in a
> > previous mail (cursor.command and cursor.prepare()) to the next
> > release of the DB API spec.
> 
> Now that you've convinced me that it is meaningful to associate only
> one statement to a cursor (at a time), I agree with your proposal.

I think it adds needless complication, and raises the bar for new DBAPI
implementors. The implementor must now deal with additional interface
elements and maybe some feature testing. Remember: the cursor objects
could very well be written in C, so raising the bar _at_all_ is not always
a good thing. Especially when it does not specifically introduce a new
piece of functionality -- just a different name for it.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/