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<javascript:>> > 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. 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. -- 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.
