Re: documenting whether or not the seq_of_parameters to executemany is expected to be run in order given
"Mike Bayer" <[email protected]> Sun, 09 Apr 2023 09:13:52 -0400
| Newsgroups | gmane.comp.python.db |
|---|---|
| Message-ID | <[email protected]> |
--===============1409487835722507900== Content-Type: multipart/alternative; boundary=748729071dee406aaa09d443d7c5e64c --748729071dee406aaa09d443d7c5e64c Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable It's my understanding that a lot of executemany() implementations will a= ctually run the given statement once per each element in the sequence of= parameters. such as, it creates a prepared statement handle for the st= atement, then runs each parameter set. a driver that works this way can= document that executemany() is guaranteed to invoke in that order, beca= use it's a driver-determined behavior, not the database. a driver that packages all the parameter sets into a single concatenated= statement of course has a different story, they can't guarantee this or= der. but in both cases it can be documented and in the former case it can be = documented as the order being guaranteed also. On Sun, Apr 9, 2023, at 5:19 AM, Tony Locke wrote: > My initial thought is that the driver must pass the executemany > parameters on to the server without changing the order of the > parameters. Maybe that should be explicitly stated in the spec. Once > the server has the parameters then I think the behaviour becomes DBMS > dependent. I guess my philosophy is that the humble driver should just > faithfully pass things back and forth while interfering as little as > possible. >=20 > On Fri, 7 Apr 2023 at 19:09, Mike Bayer <[email protected]> wro= te: > > > > OK that's two "sure, let's absolve ourselves of this problem" respon= ses :) > > > > any opinion on executemany() being less useful if this requirement i= s not established, and/or encouraging DBAPI authors to at least *documen= t* this themselves and maybe *prefer* maintaining ordering ? > > > > > > > > On Fri, Apr 7, 2023, at 1:54 PM, Erlend Egeberg Aasland wrote: > > > > On Fri, 7 Apr 2023 at 19:15, Mike Bayer <[email protected]> w= rote: > > > > > > [=E2=80=A6] The scope here is, should pep-249 add some verbiage: "th= e order in which parameters are processed by executemany() should not be= assumed to be in the order the parameters were given". [=E2=80=A6] > > > > > > Sounds good to me. > > > > Erlend > > > > > > > > _______________________________________________ > > DB-SIG maillist - [email protected] > > https://mail.python.org/mailman/listinfo/db-sig >=20 --748729071dee406aaa09d443d7c5e64c Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso= Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>It's my underst= anding that a lot of executemany() implementations will actually run the= given statement once per each element in the sequence of parameters.&nb= sp; such as, it creates a prepared statement handle for the statement, t= hen runs each parameter set. a driver that works this way can docu= ment that executemany() is guaranteed to invoke in that order, because i= t's a driver-determined behavior, not the database.<br></div><div><br></= div><div>a driver that packages all the parameter sets into a single con= catenated statement of course has a different story, they can't guarante= e this order.<br></div><div><br></div><div>but in both cases it can be d= ocumented and in the former case it can be documented as the order being= guaranteed also.<br></div><div><br></div><div>On Sun, Apr 9, 2023, at 5= :19 AM, Tony Locke wrote:<br></div><blockquote type=3D"cite" id=3D"qt" s= tyle=3D""><div>My initial thought is that the driver must pass the execu= temany<br></div><div>parameters on to the server without changing the or= der of the<br></div><div>parameters. Maybe that should be explicitly sta= ted in the spec. Once<br></div><div>the server has the parameters then I= think the behaviour becomes DBMS<br></div><div>dependent. I guess my ph= ilosophy is that the humble driver should just<br></div><div>faithfully = pass things back and forth while interfering as little as<br></div><div>= possible.<br></div><div><br></div><div>On Fri, 7 Apr 2023 at 19:09, Mike= Bayer <<a href=3D"mailto:[email protected]">mike_mp@zzzcomput= ing.com</a>> wrote:<br></div><div>><br></div><div>> OK that's t= wo "sure, let's absolve ourselves of this problem" responses :)<br></div= ><div>><br></div><div>> any opinion on executemany() being less us= eful if this requirement is not established, and/or encouraging DBAPI au= thors to at least *document* this themselves and maybe *prefer* maintain= ing ordering ?<br></div><div>><br></div><div>><br></div><div>><= br></div><div>> On Fri, Apr 7, 2023, at 1:54 PM, Erlend Egeberg Aasla= nd wrote:<br></div><div>><br></div><div>> On Fri, 7 Apr 2023 at 19= :15, Mike Bayer <<a href=3D"mailto:[email protected]">mike_mp@= zzzcomputing.com</a>> wrote:<br></div><div>><br></div><div>><br= ></div><div>> [=E2=80=A6] The scope here is, should pep-249 add some = verbiage: "the order in which parameters are processed by executemany() = should not be assumed to be in the order the parameters were given". [=E2= =80=A6]<br></div><div>><br></div><div>><br></div><div>> Sounds = good to me.<br></div><div>><br></div><div>> Erlend<br></div><div>&= gt;<br></div><div>><br></div><div>><br></div><div>> ___________= ____________________________________<br></div><div>> DB-SIG maillist&= nbsp; - <a href=3D"mailto:[email protected]">[email protected]= g</a><br></div><div>> <a href=3D"https://mail.python.org/mailman= /listinfo/db-sig">https://mail.python.org/mailman/listinfo/db-sig</a><br= ></div><div><br></div></blockquote><div><br></div></body></html> --748729071dee406aaa09d443d7c5e64c-- --===============1409487835722507900== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DB-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/db-sig --===============1409487835722507900==--