On May 30, 2013, at 3:10 PM, Claudio Freire <klaussfre...@gmail.com> wrote:
> On Thu, May 30, 2013 at 3:45 PM, Michael Bayer <mike...@zzzcomputing.com> > wrote: >> >> 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. > > Um... that might make the task a lot bigger than it should be. I'll > have to look into it. if you look at the history of major feature adds, the actual cleverness to implement the feature is really like 10% of the effort. its about the tests, the documentation, the upgrade paths, all of that. If all I did was throw balls of clever at SQLAlchemy all day, and I have plenty, it would be a huge pile of colorful mud. All the support work is the price we pay for the joy of clever new features. >>> >> >> 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'm not so familiar with Query internals yet to answer this. But I'll > look into it. I've been thinking, that if caching is conditional on > nothing structural about the query changing, and if we just want to > support that pattern I mentioned above (where you have a global query > object from which you build session-bound ones with "with_session"), > it could be as cheap as taking the internals' identity as hash. That > wouldn't work for the usual query building patterns, but then again, > when you build a new object, you're already paying a cost similar to > compiling, so caching would only really benefit the case where you > cache the expression externally. > > In case I'm not clear, this would not be cached if I were to take > id(internals) > > query(Blah).filter(blah).join(blah).first() > > But I don't care, because that's "expensive" on its own. result caching (because we're calling first()) is a whole different thing. the dogpile.cache recipe addresses that - its a widely used recipe and sure, that would make a great feature too, I keep it as a recipe so that people who use it have spent time understanding it. Recipes are for features that I don't have time to make 300% bulletproof, basically. -- 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.
