|
From: Nick E. <ne...@gm...> - 2009-08-18 15:42:16
|
That should of course be:
cursor.execute(query % str(types))
On Tue, Aug 18, 2009 at 10:37 AM, Nick Edds <ne...@gm...> wrote:
> I was under the impression that repeat use of a query was for performance
> given this in the documentation of execute:
>
> The prepared dynamic SQL will be reused by the cursor if the same SQL is
> passed in the sql argument. This is most effective for algorithms where
> the same operation is used, but different parameters are bound to it (many
> times).
>
> If the parameters are not being used for performance though, how is your
> solution superior to the naive:
> query = 'select foo from bar where baz in %s'
> types = ('A', 'B', 'C')
> cursor.execute(query % types)
>
> which is more transparent.
>
> If the performance gains are of significance from repeat use of a query,
> your solution has the advantage that the cursor will reuse the prepared
> dynamic SQL for the 2nd+ time using any particular number of items.
>
> Nick
>
>
>
> On Tue, Aug 18, 2009 at 10:27 AM, Deron Meranda <der...@gm...>wrote:
>
>> On Tue, Aug 18, 2009 at 11:19 AM, Nick Edds<ne...@gm...> wrote:
>> > But what if later you want to run the query with items = ['A', 'B', 'C',
>> > 'D']?
>> >
>> > Then you're going to need to construct a new query because the original
>> > query can only support 3 items., so you lose the performance gain of
>> making
>> > a query that takes parameters. I can't really see a better solution
>> though.
>>
>> Constructing the query and args dict using the list comprehension
>> methods I showed will equally work for any sized list of items (>=1)
>> without changing any python code.
>>
>> As far as I'm aware the substitution mechanism in the DBI is not
>> there for performance; but is primarily there to make it easier to use,
>> to facilitate automatic type conversions, and to help prevent mistakes
>> in escaping and quoting SQL literals.
>>
>> I suspect any performance loss or gain will be negligible.
>> --
>> Deron Meranda
>>
>
>
|