[DB-SIG] Clarification of cursor.arraysize
aprotin at research.att.com
Tue Dec 19 16:28:18 CET 2006
Carsten Haese wrote:
>On Mon, 2006-12-18 at 16:56 -0500, Art Protin wrote:
>> I find yet again that I am confused by what I read in pep-0249.
>>This time it is the last line describing the attribute of cursor objects
>>named .arraysize (I quote here both paragraphs):
>> This read/write attribute specifies the number of rows to
>> fetch at a time with fetchmany(). It defaults to 1 meaning
>> to fetch a single row at a time.
>> Implementations must observe this value with respect to
>> the fetchmany() method, but are free to interact with the
>> database a single row at a time. It may also be used in
>> the implementation of executemany().
>>I fail to grasp how .arraysize could have any bearing on .executemany()
>>or for that matter any operation other than fetchmany(). Thus I find I
>>must request aid in understanding what the intent is here - HELP, please.
>It says "It *may* be used in the implementation of executemany()." I
>imagine this would be useful for a database API that allows passing
>parameters in bulk. You're free to implement executemany() without
>referring to arraysize if there is no advantage in referring to
I am probably being dense here, but ... This seems to be like saying
"The implementor is free to transfer parameters for .executemany() in
groups of 17, or not." Why mention it at all?
Did someone write an interface that did tie the value for the number of
rows to transfer to the value for the number of sets of parameters to
transfer? I suspect that some piece of the historical debate in
developing this specification may have been lost here.
I think that either the specification should omit that last line or
include enough additional information to permit the reader to see not
only how they can be linked (actually that IS simple enough to be left
out) but a reason why an implementation might benefit from having them
linked (which I still have not heard and am limited enough to not be
able to imagine for myself).
>> While I am bothering you good people with my silly questions, I
>>might just as well tack on another: if one invokes .executemany with a
>>seq_of_parameters that is empty (like
>>) shouldn't the interface module execute the query zero times, ie, not
>>execute the query at all?
>Yes, executemany() with an empty sequence is a no-op.
Thank you all,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the DB-SIG