[DB-SIG] Clarification of cursor.arraysize

Carsten Haese carsten at uniqsys.com
Tue Dec 19 16:55:29 CET 2006


On Tue, 2006-12-19 at 10:28 -0500, Art Protin wrote:
> 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?

It's an implementation hint. Take it or leave it.

> 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.

Anecdotal evidence from
http://mail.python.org/pipermail/db-sig/2003-March/003294.html suggests
that cx_Oracle at some time referred to arraysize in executemany(), but
I don't have any insight into the code to confirm or deny this.

> 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).  

There is no inherent benefit in "linking" executemany() and arraysize,
except when the underlying API allows passing multiple parameter sets in
bulk, thus reducing the number of communication round-trips. If such an
optimization is possible, you need to know how many parameter sets to
pass in each batch, and looking at the arraysize seems like an obvious
thing to do.

If such bulk execution is not possible, feel free to interact with the
database one parameter tuple at a time.

Hope this helps,

Carsten.




More information about the DB-SIG mailing list