1.  

    Or maybe configure loading properly, including failing on unexpected loads early.

    1.  

      Sounds like a good solution if you are looking to optimize your queries. Honestly, we aren’t.

      A simple example is a Rest Framework model API. We want to use this API for getting different data fields every time. There is no smartness in the ORM to decide whether to pre-fetch or not. Unless I take time to optimize each of the cases manually (or mindlessly always do JOINs which I don’t need), I can’t make it return me the data in an efficient way.

      1.  

        why aren’t you looking to optimize your queries?

    1.  

      Adding plug and play Caching is a no brainer, you can get significant optimizations by doing nothing, even with badly written queries.

      I don’t think it’s that simple. There’s a reason cache invalidation comes up every single time someone makes a “two hard problems in computer science” joke.

      A better framing would be - “If you introduce caching, be very careful. It’s not a no brainer.”

      1.  

        Completely agreed that cache invalidation is hard.

        In the above blog, I am working with a Caching library which takes care of invalidations. Note that the Cachalot library is highly inefficient, it drops all Querysets related to the model in case of a single object being changed. If that’s a red flag for you, then you shouldn’t use it. It works very well for our use case.