[DB-SIG] Proposed DB-API extensions

[Anthony Tuininga]

On Wed, Mar 19, 2008 at 7:25 AM, Carsten Haese <carsten at uniqsys.com> wrote:
> 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.

+1. I agree with this as well. I did not implement this in cx_Oracle
but I did in ceODBC after seeing it used to great advantage in another
driver -- I forget which one, though. :-) I'll be looking at putting
this into cx_Oracle as well.

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

I don't see much advantage here either but if the first enhancement is
included then it becomes very simple to implement anyway and it could
be nice syntax sugar. :-)

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

+1 from me but that would be obvious considering that cx_Oracle
already implements this. :-) Having __enter__ and __exit__ used for
closing a connection seems pointless since you can just as easily use:

with contextlib.closing(connection):
    # do something

Having to do this:

try:
    # do something
   connection.commit()
except:
   connection.rollback()
   raise

seems to me to be precisely what context was about in the first place!
And generally a connection is used frequently so using __exit__ for
closing a connection would be very infrequently used at best.

with connection:
    # do something

is far cleaner, 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__ .

It seems to me to be extra work for little advantage but if everyone
else disagrees with me I have no particular issue with this
suggestion.

>  > ==> fetchscalar method in cursor object
>
>  +0. I have no problem with implementing this, but I don't see much use
>  for it myself.

Agreed. I haven't felt the need for this myself.

>  Best regards,
>
>  --
>  Carsten Haese
>  http://informixdb.sourceforge.net
>
>
>  _______________________________________________
>  DB-SIG maillist  -  DB-SIG at python.org
>  http://mail.python.org/mailman/listinfo/db-sig
>