On May 30, 2013, at 2:28 PM, Claudio Freire <klaussfre...@gmail.com> wrote:
> >> 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. well the current tests suffer very much from years of being integration tests and not unit tests. These tests would actually do a terrible job of testing this cache, as almost all tests use a brand new mapping, a brand new session, and emit just one query. none of the things that can go wrong with caching, such as the multiple result issue you're describing with the bake() recipe, would be exercised by current tests. Memory leaks, subtle changes in queries, all that stuff. It also sort of depends on how the feature comes out, how hard it will be to verify its correctness. > >> 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. Can't a Query generate its hash from its current state, without generative methods being called ? Otherwise, the generative methods do run through a common system, which is the @_generative decorator. I might guess that the way Query stores its state could be changed to make this whole job easier. That is, if it stored state using a whole system of objects with a known combined hashing scheme, rather than ad-hoc things like _whereclause, _order_by , etc. I'm not sure how to do this but it would certainly be some kind of system that is largely transparent even to the internals - the internals might need to change how they represent state changes, but there wouldn't be any explicit mention of hashes inside of say filter_by(), for example. -- 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.
