On Fri, May 31, 2013 at 11:29 AM, Michael Bayer <mike...@zzzcomputing.com> wrote: > > > On Friday, May 31, 2013 10:18:41 AM UTC-4, Klauss wrote: >> >> On Thu, May 30, 2013 at 7:04 PM, Michael Bayer <mik...@zzzcomputing.com> >> wrote: >> > >> > The hashing thing really has to start as a core concept first. It's a >> > big job but would be very helpful for caching scenarios and would allow us >> > to build this feature on Query without too much difficulty. The nice thing >> > about "unhashable" is that simple queries will be hashable, but as soon as >> > complexity increases you'd start seeing unhashables come in, preventing us >> > from caching something that isn't actually easy to cache. >> >> AFAIK only py3 has support for making user classes unhashable. > > > I'm not considering using `__hash__()` for this, I'd rather keep it as a > special method for this purpose. > > But after sleeping on it, I'm still pretty skeptical, because it's actually > pretty difficult to determine what parts of a statement will remain > "constant" across backends.
It's not necessary to be constant across backends. All of compiled_cache machinery already appends the dialect so only "semantically constant" would be required. > If you have a select like, "SELECT x + ? FROM q", where ? is a bound > parameter, that statement won't run on some backends which don't allow bound > parameters in the columns clause. So a select() object "select([x + 3])", > we would theoretically have to include the number "3" as part of its cache > key...but based on where the "3" is present. Similar things happen when > you say select().limit(x) - LIMIT can usually be rendered via bound > parameter, but not on backends like Sybase or SQL Server where it is > rendered in the TOP clause that can't be bound. So yeah, you don't have to care about that. It's taken care at other levels. Hashing should be concerned with semantics only. -- 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.
