[DB-SIG] DBAPI-2.0 clarifications
Mon, 19 Mar 2001 13:41:40 +0100
Federico Di Gregorio wrote:
> Scavenging the mail folder uncovered brian zimmer's letter:
> > I believe they are required to see the changes immediately. Opening two
> > connections is the only way to isolate the transactions. Essentially, and
> > please correct me if I'm wrong, a cursor is only a statement from a
> > connection and has no transactional ability on it's own, so the connection
> > must handle them as all together or commit on each one.
> ok, this is clear. so what about putting this stuff in the DBAPI document?
> just to avoid unneccesary quastions on the same argument in the future...
Patches welcome ;-)
> > > ok. now, how are multiple SELECTs derived from calling executemany()
> > > on a SELECT statement supposed to work? all the results should be
> > > concatenated into a single set? or we can extend .nextset() to cover
> > > this situation?
> > I have the same question. Consider this example:
> [example snipped]
> can please the dbapi authors comment on this? thanx...
I think the docs on .nextset() are clear about this. .fetchXXX()
APIs only work on the current result set and a call .nextset()
advances to the next available result set.
cursor.execute('select * from mytable where id = ?', [(1,), (2,)])
resultsets = 
if not cursor.nextset():
resultsets ... [[(1,'first')], [(2,'second')]]
> > > "These two fields can probably be safely set to None" is, imho, not good
> > > *unless* the api specifies that the two fields are optional. this is
> > > why i am asking all that questions and why (in the future) i will probably
> > > propose a little revision of the API to clarify the obscure points.
> > For what it's worth I set them to None as well.
> ok. lets say that all the fields, from 2 onward are optional and should
> be set to None if not implemented. what about putting this in the DBAPI?
> DBAPI editor?
Good idea. Could you send in patches for this ?
> > I've included my small testing framework as an example of how I test. I
> > utilize PyUnit and can test just about any DB API 2.0 compliant
> > implementation. I essentially read an xml document describing the factory
> > method which opens the connection and then run the connection through any
> > number of tests. It works in jython as well as cpython with no additional
> > changes. Try changing the sample 'test.xml' to your factory method and see
> > if it works, I'd be quite curious. It works perfectly well for mxODBC and
> > zxJDBC at the moment as both are set in the xml document.
> looking at it, thank you very much,
Perhaps we ought to put this somewhere on the db-sig page or
into the database topic guide... Andrew ?
Company & Consulting: http://www.egenix.com/
Python Pages: http://www.lemburg.com/python/