2008/3/19 Gerhard Häring <[EMAIL PROTECTED]>:
> I'd like to propose the attached changes to the DB-API spec. My main
> motivation is to make DB-API modules less cumbersome to use when used
> directly.
> ==> .execute(), .executemany() returning self.
+1
> ==> .execute(), .executemany() in con
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
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 stat
I'd like to propose the attached changes to the DB-API spec. My main
motivation is to make DB-API modules less cumbersome to use when used
directly.
If you want to try it out live, everything except .fetchscalar() is
already implemented in pysqlite. The __enter__/__exit__ thing is in
pysqlite
Gerhard Häring wrote:
> Robert Rawlins - Tamed Technology wrote:
>> Essentially I only have a single database attached to my application
>> but I’m looking for the best way to handle its connection so thought I
>> would come and get your thoughts and opinions.
>> Within my applications I’ll have
