Michael Bayer wrote:
>
> Michael Bayer wrote:
>>
>> Jonathan Marshall wrote:
>>>
>>> How is the sqlalchemy's outptut of parameters generated? It has the
>>> wrong value in it.
>>
>> hold that thought, I've reproduced the bug.
>
> its a hash collision resulting from a hopefully undocumented usage of the
> "params" dict you send to execute, whereby you can place a bindparam()
> construct as a key in that dict. the bindparam() objects are created by
> the text() construct, the hash values compare because after a lot of
> values, you get a hash collision against the integer values being sent in,
> and __eq__() returns True since all clauseelements produce an object
> that's not False.
>
> Since we had 0.5.4p3 scheduled for launch very soon, I'll look for a
> workaround for this or remove the behavior altogether if I can get a sense
> that nobody is using this feature.
>
the behavior is removed in r5991. 0.5.4p3 is probably out today which
was already planned.
I'd be very surprised if anyone was using this behavior since it was never
documented, it essentially looks like:
bar = bindparam("bar")
s = table.select().where(table.c.foo == bar)
conn.execute(s, {bar:5})
All of our documentation would write this as:
conn.execute(s, {"bar":5})
So its the {bar:5} feature that is removed.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
