[DB-SIG] First patch to DBAPI

[Federico Di Gregorio]

--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

here is the first little patch to the dbapi document. note that i 
don't have included the changes on .executemany() because the discussion 
is not finished. in particular the following paragraph from the
current document seems to go *agains* the ".executemany() produces
multiple result sets" argument. 

          Modules are free to implement this method using multiple
          calls to the <CODE>execute()</CODE> method or by using
          array operations to have the database process the
          ^^^^^^^^^^^^^^^^
          sequence as a whole in one call.
                   ^^^^^^^^^^

it is a big change and i'll wait fora *group* decision before 
sending a patch.

ciao,
federico

-- 
Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology              fog@mixadlive.com
Debian GNU/Linux Developer & Italian Press Contact        fog@debian.org
             A short story: I want you. I love you. I'll miss you. -- Me

--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="DatabaseAPI-2.0.html.diff"

--- DatabaseAPI-2.0.html	Fri Feb 23 12:09:39 2001
+++ DatabaseAPI-2.1.html	Mon Mar 19 19:24:38 2001
@@ -362,7 +362,9 @@
 	    forward; an <CODE>Error</CODE> (or subclass) exception
 	    will be raised if any operation is attempted with the
 	    connection. The same applies to all cursor objects trying
-	    to use the connection.
+	    to use the connection. Note that closing a connection without
+	    committing the changes first will cause an implicit
+	    rollback to be performed.
 	    <P>
 
 	  <DT> <B>commit</B>()
@@ -408,7 +410,13 @@
 
 	<P>
 	  These objects represent a database cursor, which is used to
-	  manage the context of a fetch operation.
+	  manage the context of a fetch operation. Cursors created from 
+          the same connection are not <I>isolated</I>, i.e., any changes
+          done to the database by a cursor are immediately visible by the
+          other cursors. Cursors created from different connections can
+          or can not be isolated, depending on how the transaction support
+          is implemented (see also the connection's <CODE>rollback()</CODE> 
+          and <CODE>commit()</CODE> methods.)
 	<P>
 	  Cursor Objects should respond to the following methods and
 	  attributes:
@@ -421,10 +429,15 @@
 	    This read-only attribute is a sequence of 7-item sequences.
 	    Each of these sequences contains information describing one
 	    result column: <CODE>(name, type_code, display_size,
-	      internal_size, precision, scale, null_ok)</CODE>. This
-	    attribute will be <CODE>None</CODE> for operations that do not
-	    return rows or if the cursor has not had an operation invoked
-	    via the <CODE>executeXXX()</CODE> method yet.
+	    internal_size, precision, scale, null_ok)</CODE>. The first 
+            two items (<CODE>name</CODE> and <CODE>type_code</CODE>) are
+            mandatory, the other five are optional and must be set to 
+            <CODE>None</CODE> if meaningfull values are not provided.
+           <P>
+              This
+	      attribute will be <CODE>None</CODE> for operations that do not
+	      return rows or if the cursor has not had an operation invoked
+	      via the <CODE>executeXXX()</CODE> method yet.
 	    <P>
 	      The <CODE>type_code</CODE> can be interpreted by
 	      comparing it to the <A HREF="#types">Type Objects</A>

--PEIAKu/WMn1b1Hv9--