News for hackers. Stuff that matters.
Re:Harmful Defaults in Django by jmconfuzeus on Friday January 07, 2022 @09:04AM (#29839195)
That's the point. Instead of worrying about whether you're accessing a related attribute, join everything and evaluate the QuerySet before passing it to context.

You'll never have to worry about whether {{ pizza.topping.name }} is hitting the database ever again, especially, if you install django-zen-queries because it will raise an exception if you try to.

Re:Harmful Defaults in Django by Nextgrid on Friday January 07, 2022 @10:14AM (#29840036)
Got it - so the magic here isn't merely to evaluate querysets ahead of time (which can still return objects with unfetched relations that'll cause a query at runtime if accessed) but to also rely on the third-party package to explicitly disallow that.
Re:Harmful Defaults in Django by jmconfuzeus on Friday January 07, 2022 @12:12PM (#29841694)
It's highly unlikely that will you execute unnecessary queries from view code because usually you'll have a context like {"pizzas": page_obj.object_list}. You'll almost never execute something like:

  for pizza in pizzas:
      print(pizza.topping.name)
But you'll certainly do the following in templates:

  {% for pizza in pizzas %}
    <p>{{ pizza.topping.name }}</p>
  {% endfor %}
I also don't understand why you want to avoid 3rd party packages, especially if it helps you write better code.
Re:Harmful Defaults in Django by Nextgrid on Sunday January 09, 2022 @03:07AM (#29861330)
My argument was that the third-party package is what's key here. Merely converting your querysets to a list in code before handing it off to the template won't fully protect you against extra queries.

I'm not necessarily trying to avoid third-party packages, in fact I've installed the package you suggested in one of my projects and will be trying it out.