[DB-SIG] Re: [PyGreSQL] Version 3.0 PyGreSQL

Greg Stein gstein@lyra.org
Fri, 12 May 2000 04:05:13 -0700 (PDT)

On Fri, 12 May 2000, M.-A. Lemburg wrote:
> Greg Stein wrote:
> > Understood, but I've never seen the utility of doing the prepare() ahead
> > of time (as opposed to simply waiting for that first execution to occur).
> > After that point, the current mechanism and your prepare/command are
> > equivalent.
> As I said: it's very useful for implementing a cursor pool. That's
> what I use it for with great success (ODBC allows you to separate
> the prepare and execute step, so adding .prepare() was no big
> deal).

But why not create cursors and let them hang around? Why prepare them

Seems simple to just do this:

  class PreparedCursor:
    def __init__(self, conn, statement):
      self.cursor = conn.cursor()
      self.statement = statement
    def run(self, args):
      return self.cursor.execute(self.statement, args)
    def __getattr__(self, name):
      return getattr(self.cursor, name)

No need to change the API or to prepare cursors ahead of time.

It just doesn't seem to buy you much to add the prepare/command stuff.

> > Introducing prepare/command is Yet More Stuff for a person to deal with.
> It's optional, so if a DB interface writer doesn't like,
> she doesn't have to implement it.

Woah. Bad attitude :-)

ODBC is a mess because parts are optional. It is so big and with many
"optional" features or varying ways to do things.

One of the nice things about the DBAPI is that you are pretty well
guaranteed that ALL of its methods are implemented. Some of that guarantee
actually broke in DBAPI 2.0, though :-(

By keeping the definition small, you can guarantee that it will be
available and implemented. The bigger and more optional you make it, the
more you do disservice to the users. They can't rely on a feature without
doing feature-tests first, thus introducing additional code paths and
complexity into their code.

Back to prepare/command: the feature seems marginal, and then to say
"well, you don't have to implement it" is just the icing on the cake...
:-)  The "cursor pool" just isn't selling me...


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