On Fri, May 31, 2013 at 12:46 PM, Michael Bayer <mike...@zzzcomputing.com> wrote: > this hash works for backends that can render LIMIT as a bound parameter. It > will *not* work for SQL server which cannot render LIMIT as a bound parameter. > > If the hash is determined at the level of Query, we *do not* know whether or > not the backend supports LIMIT as a bound parameter, unless we ask it. > > So OK, we make more rules - ask the backend if LIMIT can be hashed as a bound > parameter. > > But then what if a particular backend has more restrictive "bound parameter" > rules than Query is aware of? What if we throw the Firebird backend at it, > and all the sudden Firebird has some quirk where you can't put a bound > parameter inside of a CASE statement inside of the columns clause? How will > Query know that suddenly another deeply embedded bound parameter can no > longer be considered hashable as a bound parameter, and must be hashed as a > literal value ?
I see. The solution is to create a new object type, QueryKey, that contains both the Query and the Dialect, and builds its hash either by invoking Query.hash(dialect), or by visiting it somehow. The underlying problem is that Query cannot decide the hash by itself. Then it shouldn't try to. It should only support building a hash with respect to a specific dialect. The only thing required of it is that the hash be stable within cacheable queries of that dialect, no need to ponder about hasheability across all dialects. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
