Re: Session state per transaction

On 27/09/2012 00:58, Daniele Varrazzo wrote:
[snip]
> - should we have a prepare() method to be called to manually prepare a
> query? How to refer to the prepared query? Should prepare return a
> name/opaque object? Should it just intern the string and detect that
> the same query is used by execute()?
> - should we have a connection subclass preparing all the queries you
> throw at it (until a certain limit after which start discarding the
> older ones)?

Preparing statements is useful only in a limited set of scenarios and we
should give the user as much control over them as possible. I'd use an
opaque object that keeps a reference to the connection and to the
prepared statement (in a sense it is just a smart cursor/connection
proxy, all the logic will continue to be there). The opaque object
should expose at least execute() and executemany() variations taking
only the parameters and expose the .connection and .cursor for
everything else (or we can proxy more than that...) You'll do:

prep = conn.prepare("INSERT INTO bla VALUES (%s, %s)")
prep.execute(("foo", "bar"))
prep.execute(("baz", "gaz"))
prep.connection.commit()

> So, I'd say once we know how we would use a prepare/execute feature we
> can implement it. In the meanwhile the feature can be somewhat
> prototyped by subclassing connection and cursor and mangling the
> queries with a PREPARE statement, with which we can use the current
> psycopg parameters adaptation.

Yes, we can probably have prepared statements in Python only.

federico

--
Federico Di Gregorio                         federico.digregorio@dndg.it
Studio Associato Di Nunzio e Di Gregorio                  http://dndg.it
 La macchina virtuale elabora quindi dati adempiendo le sue funzioni
  specifiche senza esistere nella realtà degli oggetti.  -- uno studente