On Thu, Dec 24, 2009 at 09:41:11AM -0500, Gerrat Rickert wrote:
[snip]
http://twistedmatrix.com/trac/ticket/3956 Add arraysize option to runQuery in adbapi
Well, as the guy who initiated this ticket, I'm certainly using adbapi.ConnectionPool with cx_Oracle. I'm not currently using any placeholders named "arraysize" or "cp_arraysize".
But you are using the keyword-parameters-as-query-parameters extension that cx_Oracle provides?
No, I am not. I probably didn't even notice this style was allowed, and likely wouldn't have used them even if I noticed. ('davep' mentioned on the ticket that he was using named binds, but didn't have an issue with using cp_arraysize as a keyword in runQuery) [snip]
I think the two positions here would be:
a: adbapi.ConnectionPool is designed to wrap DBAPI2 modules; keyword parameters to cursor.execute() are not allowed in DBAPI2; therefore adbapi.ConnectionPool can use keyword parameters for itself. b: adbapi.ConnectionPool has never really enforced DBAPI2 compliance, so people have been using it with all kinds of crazy DBAPI2 extensions and we should allow people to keep doing so as much as possible.
My cunning plan (which has somewhat backfired) was that one of these alternatives would seem sane, and one would seem ridiculous, and once the mailing list decided which was which I could go back to the ticket with that decision.
The way things are at the moment, I'm leaning towards (b), but I believe the developer who's worked on the patch leans towards (a) and I don't feel I have the authority to demand a change of approach. I left the ticket awaiting review, in the hope that somebody with more authority or firmer opinions would come along to review it (it's a pretty small change!), but the ticket's been sitting there for weeks now - I felt I needed to do something more drastic to help it make progress.
Thanks for trying to help push this along, Tim. I have no firm opinion either way. For me any solution is better than none. There doesn't seem to be any huge objections to using a "cp_arraysize" keyword param in runQuery, so it might not be the purest solution, but does seem practical.