Live data from Hacker News

Taming the beast that is the Django ORM – An introduction

davidhang.com

31–40 of 144 posts

Re: Taming the beast that is the Django ORM – An introduction

#31
I adore the Django ORM but as listed under cons... it makes it very hard to avoid accidental N+1 queries, and they don't seem interested in addressing this (https://code.djangoproject.com/ticket/30874). Yes lazy loading is neat when you're messing around on the shell, but you should absolutely not be leaning on it in production at any kind of scale. So instead you have to use unit tests to hopefully catch any N+1 queries.

Re: Taming the beast that is the Django ORM – An introduction

#32

I adore the Django ORM but as listed under cons... it makes it very hard to avoid accidental N+1 queries, and they don't seem interested in addressing this ( https://code.djangoproject.com/ticket/30874 ). Yes lazy loading is neat when you're messing around on the shell, but you should absolutely not be leaning on it in production at any kind of scale. So instead you have to use unit tests to hopefully catch any N+1 q…

What would be the best way?

Re: Taming the beast that is the Django ORM – An introduction

#34
post #32

I adore the Django ORM but as listed under cons... it makes it very hard to avoid accidental N+1 queries, and they don't seem interested in addressing this ( https://code.djangoproject.com/ticket/30874 ). Yes lazy loading is neat when you're messing around on the shell, but you should absolutely not be leaning on it in production at any kind of scale. So instead you have to use unit tests to hopefully catch any N+1 q…

What would be the best way?

If it were up to me there'd be a way to completely disable it globally for all models. Let me explicitly enable it when I'm just shelling around or checking results in unit tests. It is not a feature for production environments.

Re: Taming the beast that is the Django ORM – An introduction

#35

I adore the Django ORM but as listed under cons... it makes it very hard to avoid accidental N+1 queries, and they don't seem interested in addressing this ( https://code.djangoproject.com/ticket/30874 ). Yes lazy loading is neat when you're messing around on the shell, but you should absolutely not be leaning on it in production at any kind of scale. So instead you have to use unit tests to hopefully catch any N+1 q…

Just to say there are libraries to help you find n+1 queries too (when your code is running).

I use https://pypi.org/project/django-nplusone/ for instance. Sentry also warns of these by the way.

Re: Taming the beast that is the Django ORM – An introduction

#36

For me the killer feature of django is the auto-generated admin UI. I initially started my last project using Spring boot, but I was astonished to find there was no equivalent. I don't know how people build websites in any speed without such a tool. I guess they just waste time duplicating effort on an admin UI or pay for one of those tools that can generate one from an API (meaning they have to also build an API). I…

I used to think this too. LLms make generating such UIs in other frameworks too much easier. Also the admin UI gets clumsy very fast and you’ll need to roll your own for a good UX.

Re: Taming the beast that is the Django ORM – An introduction

#37

For me the killer feature of django is the auto-generated admin UI. I initially started my last project using Spring boot, but I was astonished to find there was no equivalent. I don't know how people build websites in any speed without such a tool. I guess they just waste time duplicating effort on an admin UI or pay for one of those tools that can generate one from an API (meaning they have to also build an API). I…

I would say even more:

- the main reason to use django today is the admin UI

- and the only reason to use django ORM is the admin UI

Re: Taming the beast that is the Django ORM – An introduction

#38
post #32

Earlier quoted context omitted.

What would be the best way?

If it were up to me there'd be a way to completely disable it globally for all models. Let me explicitly enable it when I'm just shelling around or checking results in unit tests. It is not a feature for production environments.

Would auto-joins be better in production envs?

Re: Taming the beast that is the Django ORM – An introduction

#39
post #33

ORMs do a great job at making easy things even easier and hard things a lot harder. If that sounds like a bad deal to you- it’s because it is!

The Django ORM makes migrating database state (a hard problem) super easy. It also makes GROUP BY queries (a relatively easy problem) oddly difficult. Use an ORM where it helps, use SQL where it doesn't.
Post reply on HN