[DB-SIG] DBAPI-2.0 clarifications

[Federico Di Gregorio]

Hi *,

	i am about to fix the lastest DBAPI-2.0 compliance quirks in
psycopg and to write a test suite but i need some clarifications on
some parts of the DBAPI. this will be a long post, sorry for that...


1/ cursors and transactions

  if a db support transactions, how two cursors derived from the same
  connection are supposed to see changes done to the db? if cursor A
  does an insert, is cursor B supposed to see the change suddenly or
  only after a commit() on the connection? imho, it would be better
  if the api specifies that a commit() is required, even if for the
  drivers that does not support transactions commit() is a no-op.


2/ nextset() and executemany()

  the api is not very clear on what a "set" is. it just says that not
  all db support "multiple result sets". imho, it is logical that a call 
  to executemany() (with a SELECT operation) produces multiple sets.
  is this the right interpretation or multiple result sets are something
  different? what should happen if a SELECT is passed to executemany()
  and the driver does not support nextset()?


3/ constructor objects

  are the constructor objects (Date, Time, Binary) expected to return
  a valid *already quoted* string? and what method should return the
  string, __repr__() or __str__()? i'll bet on __str__ but i am not
  sure. a little example to better explain: if a generate the object
  as t = module.Time('13:23:00') and then cursor.execute("SELECT * FROM
  table WHERE time > %(time)s", {'time':t}) the string that gets
  passed to the db is "SELECT * FROM table WHERE time > '13:23:00'",
  right? (note the quotes...)
 

4/ closing connections

  closing a connection does an implicit commit() on it? this is important
  because, following the file object style, most drivers implicitly close() 
  the connection when the object is collected by the gc and the user can
  find the program commiting changes even if it did not tell it to.


5/ the description field

  how are the precision and scale field to be interpreted? are the fields
  mandatory? sometimes obtaining the information in the description is
  plain slow (like the display_size, you have to scan every single row
  in the result set) or requires accessing system tables. very few programs
  use the most esoteric fields (most programs only use type_code and name.)
  what about (i know that this will make people flame me) add a new method
  to obtain a detailed description and put a shorter description in the
  current .description field?


thank you very much for your time,
federico (expectiong comments)
 
-- 
Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology              fog@mixadlive.com
Debian GNU/Linux Developer & Italian Press Contact        fog@debian.org
              All programmers are optimists. -- Frederick P. Brooks, Jr.