On Wed, Mar 19, 2008 at 7:25 AM, Carsten Haese <[EMAIL PROTECTED]> 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@python.org
> http://mail.python.org/mailman/listinfo/db-sig
>
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
