[wruza]

I wonder why ORMs still(?) work as simple wrappers and never track access patterns. If you see that `in books` generator’s results experience accesses through a relationship, it’s pretty obvious to join it in advance after few misses and serve `book.author.full_name` from cache.

Of course that would make ORM more complex, but why would you need one otherwise. A good database interface should make good guesses, probably with some hints that could be slapped over without changing naive code patterns. But instead we get 1000 different cool ways to create a table and select a row by id.

[danielheath]

I don't want my app to change performance-sensitive behavior at runtime, that's a debugging nightmare.

I do want my framework to throw an error in development mode if I screw up the preloading.

[wruza]

Since this also requires the same heuristics, it could be just an option: orm.unroll(“auto|throw|none”). Would suit you, me and a commenter who wants hundreds of requests as they wrote.

[nicoburns]

Because people want their queries to have predictable performance.

[marcosdumay]

Interestingly, they never get it. Every layer of the stack up to the client's database connector is unpredictable.

But yes, people want it. And will trade a lot of performance for a false promise of predictability.

[fud101]

I dont know any of this but doesn't the OP give a solution similar to this https://github.com/Suor/django-cacheops

[wruza]

It’s hard to tell by skimming through the readme, but it seems there’s no mention of this technique.

[Suor]

cacheops is more of a general purpose ORM caching with automatic invalidation.