3 ms·
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
by wruza 4y ago
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.
- nicoburns 4y agoBecause people want their queries to have predictable performance.
- marcosdumay 4y agoInterestingly, 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.
- danielheath 4y agoI 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 4y agoSince 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.
- fud101 4y agoI dont know any of this but doesn't the OP give a solution similar to this https://github.com/Suor/django-cacheops https://github.com/Suor/django-cacheops