Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ban 1+N in Django

suor.github.io

Post reply on HN
Print view View original

1–10 of 153 posts

Re: Ban 1+N in Django

#4

Post by Suor »

gus_massa wrote: post #2

There is a problem with the URL. I think this is the correct one https://suor.github.io/blog/2023/03/26/ban-1-plus-n-in-djang...

HN keeps automatically replacing the URL. It used to be a redirect before, but not anymore

Re: Ban 1+N in Django

#5

Post by gus_massa »

Suor wrote: post #4
gus_massa wrote: post #2

There is a problem with the URL. I think this is the correct one https://suor.github.io/blog/2023/03/26/ban-1-plus-n-in-djang...

HN keeps automatically replacing the URL. It used to be a redirect before, but not anymore

HN has a feature that uses the canonical address in the webpage. Is your page configured correctly?

Looking at the source:
Don't repost it again (for now). Try fixing the canonical link, and send an email to the mods hn@ycombinator.com with a short explanation and a link to this post https://news.ycombinator.com/item?id=35313565 to save them a few minutes searching. They may fix it using admin magic or ask you to repost again once the problem is fixed.

Re: Ban 1+N in Django

#6

Post by dang »

Suor wrote: post #4
gus_massa wrote: post #2

There is a problem with the URL. I think this is the correct one https://suor.github.io/blog/2023/03/26/ban-1-plus-n-in-djang...

HN keeps automatically replacing the URL. It used to be a redirect before, but not anymore

As gus_massa pointed out, HN's software uses canonical URLs when it finds them. The canonical URL on the page you submitted was http://hackflow.com/blog/2023/03/26/ban-1-plus-n-in-django, so our software used that. I've fixed it above now.

Re: Ban 1+N in Django

#7

Post by nickjj »

There is a case where having N+1 queries are beneficial.

In Rails terms, it's when you perform Russian doll caching, but you can do this in any framework. The idea is you can cache a specific X thing which might make a query to an associated Y thing. A textbook N+1 query case (ie. a list of posts (X) that get the author's name (Y)).

If you render the view without any cache with 10 things then you'd perform 20 queries but after the cache is warm you'd perform 0 queries. If item 5's Y gets updated then you only need to bust the cache for item 5 and query only item 5's Y association. Performing a preloaded query to get all X 10 things with their Y associated things could be an expensive query.

Re: Ban 1+N in Django

#9

Post by lr4444lr »

I don't disagree with the author in principle, but I find once the data gets big enough where it makes a difference, I've already shifted to using ".values()" to avoid the overhead of model creation, and the KeyErrors that will throw if I leave the query lazy is tantamount to the solution he describes.

Re: Ban 1+N in Django

#10

Post by fiddlerwoaroof »

nickjj wrote: post #7

There is a case where having N+1 queries are beneficial. In Rails terms, it's when you perform Russian doll caching, but you can do this in any framework. The idea is you can cache a specific X thing which might make a query to an associated Y thing. A textbook N+1 query case (ie. a list of posts (X) that get the author's name (Y)). If you render the view without any cache with 10 things then you'd perform 20 queries…

The downside here is a potential thundering herd issue if you’re forced to clear the cache.
Post reply on HN