Taming the beast that is the Django ORM – An introduction

I think Django&#x27;s ORM is just AMAZING. And as with every other tool, it has to be used wisely.<p>First, it let&#x27;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&#x27;re being efficient with your SQL engine.<p>Second, and even more importantly, it&#x27;s crucial in the definition of the app and the Schema. Thinking in high level &quot;classes and objects&quot; helps with the abstraction and the design of the apps. Even if you then default to raw SQU queries, thinking and building your model with class abstractions is huge.<p>Finally, there are some &quot;tiny details&quot; (but in my eyes, very important) that everybody oversees:<p>* Migrations: the way Django has designed migrations is just marvelous. We&#x27;ve migrated tons of data and changed the structure of our DB multiple times without any issues.<p>* Troubleshooting and &quot;reporting&quot;: the ability to fire a quick shell, load a few models in Django&#x27;s REPL, and do a few `.filters()` is for me key. On top of that, we add a Jupyter server connected to our read replica and we can do all sorts of reporting VERY QUICKLY. Not everybody needs a Data Lake :)<p>PS: We&#x27;ve ran Django sites accessed by millions of people per month. And we never had an issue with the ORM. Yes, sometimes I have to tell more junior devs that the gymnastics they&#x27;re doing with `select_related` and `prefetch_related` can be more easily and effectively resolved with a query. But that&#x27;s it. I&#x27;d say less than 1% of all the queries in our codebase have to be migrated to raw SQL.

I adore the Django ORM but as listed under cons... it makes it very hard to avoid accidental N+1 queries, and they don&#x27;t seem interested in addressing this (<a href="https:&#x2F;&#x2F;code.djangoproject.com&#x2F;ticket&#x2F;30874" rel="nofollow">https:&#x2F;&#x2F;code.djangoproject.com&#x2F;ticket&#x2F;30874</a>). Yes lazy loading is neat when you&#x27;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.

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!

Why Django ORM is considered a beast? It is easiest ORM to date and very convenient API to work with. If you think Django ORM is a beast, try SQL alchemy

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.<p>I don&#x27;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).<p>It&#x27;s such a massive time-saver I switched to django after a week or so.

Pretty decent introduction. Will there be additional parts that cover how to create GROUP BY queries in the ORM? I find even seasoned Django developers struggle with these.<p>Also, I believe your code for creating an empty &quot;data&quot; migration is missing the &quot;makemigration&quot; command itself.

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.<p>Routes, form validation, REST API, templating (if you don&#x27;t need react), auth, etc.<p>You&#x27;ll probably wind up recreating a lot of ORM and surrounding functionality at lower quality

Anytime I hear ORM, I always think of this: <a href="https:&#x2F;&#x2F;blog.codinghorror.com&#x2F;object-relational-mapping-is-the-vietnam-of-computer-science&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.codinghorror.com&#x2F;object-relational-mapping-is-t...</a>

orms are exercises in OCD.<p>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.<p>A better abstraction would be one that&#x27;s a bit more similar to a standard programming language with an std that has query related operations&#x2F;optimizers that can be composed so programmers can compose and choose query operations and avoid optimization issues that are hidden by high level languages like SQL.<p>We are unfortunately, sort of stuck with SQL (there are other options, but SQL remains popular because years of development has made it pretty good in spite of the fact that it&#x27;s a poor initial design choice). This is already a historical mistake that we have to live with. Same with javascript (which has been paved over with typescript), same with CSS, etc. The web is full of this stuff. It&#x27;s fine. My main problem is the ORM.<p>The ORM is just another layer of indirection. You already have a high level language you&#x27;re dealing with, now you want to put Another High level language on top of it? ORMs are basically high level languages that compile into SQL.<p>What is the point? The ORM isn&#x27;t actually making things easier because SQL is pretty much as high level of a language you can get outside of having an LLM translating direct english.<p>The point is OCD. Programmers find it jarring to work with SQL strings inside their beautiful language so they want to chop up a SQL string into web app language primitives that they can compose together. Query builders operate on the same concept but are better because they aren&#x27;t as high level.<p>This is basically the main reason why Many programmers experience the strange counter intuitive phenomena about why ORMs actually makes things harder. You have to Hack SQL to optimize it. Now you have to hack another ORM on top of it in order to get it to compile it into the hacked query.

I’ve used several ORMs and experienced the same things everyone else does—CRUD is great, but good luck with your first actual reporting dashboard.<p>Then I tried the new generation of typescript SQL query builders that automatically infer types from your database and provide end-to-end type-safe query results, even for highly complex queries. And since then I became convinced the answer isn’t trying to shoehorn classes on top of relational tables, but having a sufficiently integrated and capable query builder that provides properly typed results.

I thought Django’s ORM was awesome (seriously).<p>And yet using it was such a shit experience I switched permanently to writing SQL.<p>I see zero advantage to using an ORM over SQL and in fact see many downsides.<p>Don’t use an ORM just learn SQL. It’s faster, more direct, more powerful, easier to understand, allows you to make full use of the power of the database and your knowledge isn’t suddenly valueless when you go to a project with a different ORM.

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.<p>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 immovable and just inherent in what an ORM tries to do. Some of them just seem to be caused by not very many ORMs being good, and the writer not having used one of the better ones.

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