Dear folks,
Since I could not find a FAQ for the API (other than in the API) let
alone find my specific question, I guess I need to present it here. In
its simplest form:
When should a Cursor object discard a result set?
After reading and rereading and ... the specification (dated
2006-03-28), I infer from the existence of the method .nextset() that a
Cursor may (though not necessarily) queue up multiple result sets. I
found only three (3) methods that produce result sets: .callproc(),
.execute(), and .executemany(). Of these, the first two seem to be
allowed to produce zero or one result sets and the behavior of the third
is "undefined" if it produces even one result set. None of the
descriptions for these three methods tell what to do with any result set
from previous invocations.
I am attempting to implement an interface that complies with the
specification and can support multiple result sets (in a limited fashion
by queuing up operations) if that is what a user would expect.
Alternatively, I can make each new execution discard the previous result
set. It is even possible to make the .executemany() do both the discard
of previous results and queue up to generate result set after result set
until either another invocation of one of the three or until .nextset()
is invoked enough to go through all of them (presumably with intervening
.fetchXXX() invocations.
I think the spec should be revised to either:
variant I:
i) require a call to .nextset() to finish with each result set, and
ii) until .nextset() returns False, make each of the three either:
1) queue up to execute after .nextset() finishes with
the previous result sets, or
2) raise an exception for Cursor not ready.
variant II:
i) require each of the three to flush all previous result sets, and
ii) not return from any of the three until all queries are completed
variant III:
i) have an attribute .queueable that reflects if any of the
three will return before the query has been performed, where the attribute
A) may be changed, or
B) is readonly.
(I think it best if the code allows write attempts on
the attribute, but but may fail to change it so that the user should be
required to check the value after attempting to set it. This would
allow the specification to accommodate those that implement it
switchable or with either fixed value.)
(This goes into more detail than I intended but I do not see what to
leave out.)
Any comments will be appreciated.
Thank you,
Art Protin
_______________________________________________
DB-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/db-sig
