> On Dec 18, 2014, at 5:39 AM, M.-A. Lemburg <m...@egenix.com> wrote:
>
> On 17.12.2014 19:13, INADA Naoki wrote:
>> As I said before, prepared statement is normally bound to connection.
>> So `.prepare()` method should be connection's method, not cursor's.
>>
>> prepared = conn.prepare("SELECT ?+?")
>> ...
>> cur = conn.cursor()
>> cur.execute(prepared, (1, 2))
>> cur.fetchone() # returns (3,)
>
> I'm not sure which database you are talking about, but in terms
> of concepts, statements are run on cursors, so adding the method
> to connections doesn't look right (we dropped this logic when moving
> from DB-API 1.0 to 2.0 a long time ago).
>
> Also note that the prepare step may need access to the
> cursor configuration settings to be correctly interpreted
> by the database.
oh, so are you saying that if one produces a prepared statement from a cursor,
and then that cursor is closed, I have no option to re-use that prepared
statement anywhere else, is that right?
That would make the entire feature a non-starter for me. SQLAlchemy doesn’t
hold cursors open beyond a single statement. My users would very much want a
prepared-statement-per-transaction object.
JDBC provides prepared statements as a service of the Connection. I think
DBAPI should be doing the same.
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
https://mail.python.org/mailman/listinfo/db-sig
