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

[M.-A. Lemburg]

Greg Stein wrote:
> 
> 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
> first?
> 
> 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.

Well, it does pay off to have some more control over
when things happen (e.g. syntax errors are usually raised by the
prepare step).

But never mind... it was just an idea that was very straight
forward to implement for mxODBC.

> > > 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 :-(

Mostly because a few databases don't provide the needed services...
not implemeting a feature due to one or two interfaces not
providing them (while the remaining 20 could without problem),
doesn't seem like the right way to go, IMHO.

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

I'll let others chime in here... I only use mxODBC, so I'm pretty
much satisfied already ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/