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

Taming the beast that is the Django ORM – An introduction

davidhang.com

Post reply on HN
Print view View original

91–100 of 144 posts

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

#91

Post by oliwarner »

rowanseymour wrote: post #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 q…

Not really.

.prefetch_related (for whole models) and annotate/Subquery (for fields or aggregates) have existed for many years, alongside a pile of aggregate functions which have existed forever and have improved.

Whether or not you use the tools given to you is a sign of developer quality and experience. You can easily avoid n+1 99% of the time but you have to appreciate the problem exists.

I think the Django project demanding some competence is okay.

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

#92

Post by sgt »

nprateem wrote: post #29

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…

Most people seem to love it. I, on the other hand, tend to disable it from the start when creating a new Django project. I add shell_plus and I just use the Django REPL to explore the data (in addition to dbshell - psql in my case). That way I can type instead of having to navigate a UI.

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

#93

Post by Kalanos »

People focus too much on the query aspect of an ORM. Even though you can still write raw query strings in an ORM if you want to.

Routes, form validation, REST API, templating (if you don't need react), auth, etc.

You'll probably wind up recreating a lot of ORM and surrounding functionality at lower quality

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

#94

Post by sgt »

nprateem wrote: post #24

This is largely academic now. LLMs do a good job of writing highly complex queries with the django ORM. All you need is the django toolbar so you can check their efficiency, then keep telling it to make them more efficient.

You're welcome to use LLM's, but you need to be able to answer for every single line, every single construct, parameter and class before pushing it to production. That is your responsiblity as a developer.

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

#96

Post by nprateem »

sgarland wrote: post #89
nprateem wrote: post #24

This is largely academic now. LLMs do a good job of writing highly complex queries with the django ORM. All you need is the django toolbar so you can check their efficiency, then keep telling it to make them more efficient.

And the title of Software Engineer becomes even more meaningless. Imagine an electrical engineer saying, “I don’t really know what a bridge rectifier is, but I plugged these things into the breadboard where ChatGPT told me, and the output signal looks correct.”

The engineering is in saying "I need to get this data within these performance constraints", not in the now worthless knowledge of exactly how to fetch it.

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

#97

Post by thruway516 »

9dev wrote: post #70
ninetyninenine wrote: post #50

orms are exercises in OCD. Databases are the bottleneck your classic website. We choose to query these databases in a extremely high level language called SQL. This language is so high level that you need to come up with tricks and query analyzers in order to hack the high level query into something performant. A better abstraction would be one that's a bit more similar to a standard programming language with an std…

You are correct in your entire assessment, yet, you seem to underestimate the number of boring CRUD applications serviced by mediocre programmers. Limiting the number of technologies required to have at least a little knowledge in is a benefit, even if it hampers performance, because performance doesn’t matter for the vast majority of cases. Software engineers tend to overvalue that bit; the users of line-of-business…

I had to scroll all the way down to find this. As a CTO who personally never understood the point of ORMs the benefits become very quickly obvious when your organization starts to scale and the prospect of dozens or hundreds of developers of unknown quality hitting your production db with raw sql becomes objectively frightening. Of course there are ways to setup and administer your db to prevent the most obvious footguns, and it is still possible to write bad queries with an ORM, but having that extra layer with limitations gives some extra peace of mind.

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

#98

Post by greenie_beans »

exceptione wrote: post #58
santiagobasulto wrote: post #41

I think Django's ORM is just AMAZING. And as with every other tool, it has to be used wisely. First, it let's you get started quickly and prototype. You can write unit tests, make sure everything is working as expected, then count queries and make sure you're being efficient with your SQL engine. Second, and even more importantly, it's crucial in the definition of the app and the Schema. Thinking in high level "class…

There is one part in me that says to not destroy your positive mood, there is another part in me that wishes to yell at the pythonistas in general to look outside the Python world. Too often I come across Python projects that are hyped and when I dive into it I find it rather underwhelming to say it politely. Invariably it turns out that those people don´t know any other language than Python. I see that as a general…

no, i'm not about to go back to .net core

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

#99

Post by rowanseymour »

oliwarner wrote: post #91
rowanseymour wrote: post #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 q…

Not really. .prefetch_related (for whole models) and annotate/Subquery (for fields or aggregates) have existed for many years, alongside a pile of aggregate functions which have existed forever and have improved. Whether or not you use the tools given to you is a sign of developer quality and experience. You can easily avoid n+1 99% of the time but you have to appreciate the problem exists. I think the Django project…

Not sure you understand my complaint because forcing the user to track down N+1 queries to know where they're missing .prefetch_related is the problem. I don't want to fix something 99% of the time. I want my ORM to enforce correctness 100% of the time.

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

#100

Post by greenie_beans »

choilive wrote: post #7
cqqxo4zV46cp wrote: post #3

Django’s ORM is the first one that I ever spent a lot of time with. Throughout my career I’ve interacted with other ORMs from time to time. It wasn’t until I’d done that, that I realised, even though it’s not perfect, how fantastic the Django ORM is. I thought they’d all be that good, but no. I’ve read a lot of criticisms of ORMs, as I’m sure everyone else has. Some of them are certainly valid criticisms that are imm…

Django's ORM is acceptable - but I think Rails/ActiveRecord is superior albeit certainly more opinionated. Most likely just my personal bias speaking because Rails was the first web "framework" I cut my teeth on.

i've used both. they both have pros/cons. use whatever tool your team is most proficient with/stop wasting your time arguing about which framework is best
Post reply on HN