On Mon, 2006-11-13 at 02:17 -0500, Martin Blais wrote: [snipped attribution to Paul Moore restored] > Paul Moore wrote: > > "Martin Blais" <blais at furius.ca> writes: > > > > > I want to propose a few improvements on the DBAPI 2.0 Cursor.execute() > > > method interface. You can find the details of my proposed changes > > > here: > > > http://furius.ca/pubcode/pub/conf/common/lib/python/dbapiext.html > > > > [...] > > However, you assume that the "second stage", of adding variable > > bindings supplied in the cursor.execute call, is also a string > > formatting exercise (just with automatic escaping). This is most > > certainly not the case in Oracle - the query is sent to the DB engine > > as given, with variable placeholders intact, and the variable bindings > > are sent independently. > > > I think you are mistaken (either that or I do not understand what you > mean, or perhaps > you haven't read the proposed code). My proposal does not modify the > way the escaped > parameters are to be sent to the client interface. In fact, the test > implementation merely rewrites the query to take advantage of the Pythonic > interface, with the exception that it may create :parameters if needed, for > example, if you pass in a list or a dict. > [...]
And yet you are still talking about escaped parameters, both in your emails and your proposal. Please try to grasp the concept that in many (most?) database engines, there is no escaping of any kind going on. In real database APIs, there are separate API calls under the hood, one for preparing a statement, one for binding parameters to the prepared statement, and finally one for executing the query. > [...] > The proposed test implementation should work fine > with cx_Oracle, i.e. will maintain :id in the string, only it will provide a > more flexible interface, for example, you could pass a list and it would > create > the necessary :parameters to be sent to cx_Oracle. Your proposal appears very much geared towards executing queries in circumstances where key information about the query is unknown at design time and only known at run-time. Such circumstances do exist, for example when you're implementing an ORM. However, this use case is much rarer compared to most real-life usage where you do know exactly at design time which table and which columns you're working with. Feel free to implement your proposed extension as a wrapper around DB-API. You're probably not the only one who might find it useful. I just don't think it's useful enough to be part of the standard DB-API. -Carsten _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
