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 opinion. 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. Best regards, -- Carsten Haese http://informixdb.sourceforge.net _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
