[DB-SIG] Proposed DB-API extensions
carsten at uniqsys.com
Wed Mar 19 14:25:08 CET 2008
On Wed, 2008-03-19 at 13:23 +0100, Gerhard Häring wrote:
> ==> .execute(), .executemany() returning self.
+1. I agree that this is nice to have.
> ==> .execute(), .executemany() in connection object.
-0. Most queries get executed more than once. Not explicitly creating a
cursor to cache the statement negates the advantage of statement
caching, or it would make statement caching harder to implement.
This feature adds convenience for executing one-of queries, but I'm
worried people might use it in circumstances where creating a dedicated
cursor object would result in better performance.
> ==> __enter__ and __exit__ in the connection object...to automatically wrap database code in transactions
-1. InformixDB uses connection.__exit__ to close the connection, whereas
cx_Oracle uses connection.__exit__ to commit/rollback a transaction, so
the train for standardizing this has left the station already. Also, I
think explicitly committing or rolling back is a Good Thing in my
I would however not be opposed to making a new connection method that
would return a "transaction context" object with the proposed behavior.
(For sqlite and cx_Oracle, this would merely be a shim that returns
self.) That way, the fact that a transaction is being managed is
explicitly visible, and we avoid the pre-existing incompatible use cases
for connection.__exit__ .
> ==> fetchscalar method in cursor object
+0. I have no problem with implementing this, but I don't see much use
for it myself.
More information about the DB-SIG