On Thu, May 30, 2013 at 2:25 PM, Michael Bayer <mike...@zzzcomputing.com> wrote: > > On May 30, 2013, at 11:25 AM, Claudio Freire <klaussfre...@gmail.com> wrote: > >> >> That way, one could use the second form up there and benefit from >> query hashing, because session/param binding wouldn't change the hash, >> and it would be a cache hit. Has it been explored already? Or maybe >> there's something wrong on how I'm using the compiled_cache thing? >> Should I start patching? ;-) > > there is a very wide gap between working with the baked query recipe, for > which I'm not aware of all the errors you refer to so more detail would help
Um... I don't remember the exact problems, will have to try it again. I just assumed it was targeted at an older SA release and gave up on it rather quickly. > and that of patching SQLAlchemy with new features. In particular I can't > imagine how it would cache results, there is nothing like that in the recipe > or compiled cache system. Something with sharing the context among query instances, since query instances cache results (or that I heard). Not sure about the specifics of how that happened, but I did notice, after patching up the recipe to not throw exceptions, that it would always return the results for the first call. The queries themselves had no bind parameters or anything, they would just return different results each time due to concurrent updates to the database. Maybe that wasn't expected for that recipe? In any case, I just gave up on it without looking into it much. > If you want to work on a feature that is actually going to change SQLAlchemy, > (and would that be before or after you finish #2720? :) ), it would be: After, I didn't forget, just real life real work priorities made me veer away from it. Since it was for 0.9, I judged I could safely delay 2720 a bit while I take care of work related priorities ;-) > 1. there is no bake() method, the entire thing is transparent > > 2. as one calls session.query(X).filter(Y).join(Z), the hashing scheme is > working the entire time in the background against a single LRU cache, that is > perhaps per sessionmaker(), or otherwise, to produce cached versions of the > Query. Everyone would get the performance gains for free in all cases. A > flag or other system would exist to turn the feature off for those who are > heavily subclassing Query and having issues or other edge backwards > compatible issues. That would mean Query objects would by default take the compiled_cache from the session, and not only during flushes but always. If that's alright, sure. > 3. it would just be on by default in a new major release like 0.9 or 1.0 I had assumed that much. > 4. it would have a super crapload of very complete and clean unit tests. Ehm... I would imagine all the current tests involving Query would cover most of it. A few more cache-specific tests could be added surely, but only to check caching is indeed happening, correctness should be checked by existing tests already. > Otherwise, the bake() recipe as it is can be enhanced or augmented with > __hash__() methods and all that but I'm not aware of anything regarding it > that would require changes to SQLAlchemy itself, since it uses a Query > subclass. Well, yeah, I guess so. But that subclass would have to step on all of Query methods to be able to compute, cache and update the hash (computing it always would be almost as costly as compiling, so it has to be cached in an instance attribute). That'd be a chore, and it would break every other release. -- 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.
