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

131–140 of 144 posts

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

#131

Post by AbundantSalmon »

WesleyJohnson wrote: post #10

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. Also, I believe your code for creating an empty "data" migration is missing the "makemigration" command itself.

Good topic for a second blog post/skill share. Are there any other interesting topics you can think of? I think I know so much but in it too deep to remember what is unusual. These came up with the recent onboarding of some new devs.

Thanks, I will update the data migration code!

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

#132

Post by nprateem »

AmericanChopper wrote: post #122
nprateem wrote: post #85

Earlier quoted context omitted.

Because it's not about avoiding SQL (although that's a benefit), it's that you also get forms for free, view classes, easy APIs, validation, a free admin, free docs and a large pool of potential employees who all understand the foundations of your app.

You don’t get any of that for free. You get it at the cost of working with the abstractions, which can be very high. Your RDBMS is not an OOP/multi-paradigm system like Python is (or whatever other language). Its objects interact differently, and it has different access patterns. Any system you use to try and ignore these differences is just going to create a host of other problems for you, especially this idea that…

With LLMs I've managed to ignore these issues so far on my django app with 100+ views and 50+ models. So yeah, I get that for free. My app is more complex than a simple CRUD app, but still at least 90% CRUD.

The benefits far outweigh the disadvantages.

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

#133

Post by AmericanChopper »

nprateem wrote: post #132
AmericanChopper wrote: post #122

Earlier quoted context omitted.

You don’t get any of that for free. You get it at the cost of working with the abstractions, which can be very high. Your RDBMS is not an OOP/multi-paradigm system like Python is (or whatever other language). Its objects interact differently, and it has different access patterns. Any system you use to try and ignore these differences is just going to create a host of other problems for you, especially this idea that…

With LLMs I've managed to ignore these issues so far on my django app with 100+ views and 50+ models. So yeah, I get that for free. My app is more complex than a simple CRUD app, but still at least 90% CRUD. The benefits far outweigh the disadvantages.

To be fair it sounds like LLMs are managing that for you. You’ve got two (mostly) black boxes stacked on top of one another here. You’ve avoided managing your DB and avoided managing your ORM. What will you do when something eventually goes wrong? Ask the LLM to fix it?

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

#134

Post by aitchnyu »

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…

Is there an admin ui which has finegrained horizontal and vertical permission depending on user? Django admin assumes admins have God-level control over all registered tables.

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

#135

Post by nprateem »

AmericanChopper wrote: post #133
nprateem wrote: post #132

Earlier quoted context omitted.

With LLMs I've managed to ignore these issues so far on my django app with 100+ views and 50+ models. So yeah, I get that for free. My app is more complex than a simple CRUD app, but still at least 90% CRUD. The benefits far outweigh the disadvantages.

To be fair it sounds like LLMs are managing that for you. You’ve got two (mostly) black boxes stacked on top of one another here. You’ve avoided managing your DB and avoided managing your ORM. What will you do when something eventually goes wrong? Ask the LLM to fix it?

Yeah. Or apply my brain. Reviewing LLM-written code is no different to working with code from a colleague or library. It's the best of both worlds, certainly while iterating quickly on the MVP & early stages.

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

#136

Post by nprateem »

ruthmarx wrote: post #129
nprateem wrote: post #83

Earlier quoted context omitted.

I've used it to write horrendously complex queries across multiple tables. It can do things I don't know how to and that would have taken significant time to learn. All I know is it works and it's performant when you tell it to be. It's been particularly helpful for aggregations, subqueries etc. You may not think LLMs are there yet but my project is proof. Try it yourself.

> It can do things I don't know how to and that would have taken significant time to learn. All I know is it works Until it fucks up and you have no clue how to fix it, and either does the LLM.

Or just read the code like I would if a colleague had written it, or do you think it's chucking out assembler?

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

#137

Post by rollcat »

Kalanos wrote: post #95
v3ss0n wrote: post #54

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

I used sqlalchemy once. I found it more complicated with way less functionality

As someone who's had numerous grand battles with both, I find that SQLAlchemy's overall design philosophy gives you more precise control over both the generated SQL, and the lifecycle of each query/transaction/connection; you get to choose exactly how much abstraction you need for the task, but it won't hide things from you where you MUST make a conscious decision. I find it's also a better choice of the two, if you're writing something that has absolutely NOTHING to do with web whatsoever (e.g. a DB-backed desktop app), as you don't have to drag in a whole kitchen sink just to drink a glass of water; but you may also want to investigate something lighter than SQLAlchemy for that use-case.

Meanwhile Django's ORM just does the job perfectly fine in the 99% common case, and for the 1%, again 99% of the time it has enough escape hatches to solve the hard problems without making things excessively complicated. But $DEITY save you if you're in that 0.01%...

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

#138

Post by ruthmarx »

nprateem wrote: post #136
ruthmarx wrote: post #129

Earlier quoted context omitted.

> It can do things I don't know how to and that would have taken significant time to learn. All I know is it works Until it fucks up and you have no clue how to fix it, and either does the LLM.

Or just read the code like I would if a colleague had written it, or do you think it's chucking out assembler?

What good will reading the code do you when by your own admission you can't understand it?

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

#139

Post by charettes »

rowanseymour wrote: post #103
stavros wrote: post #73

Earlier quoted context omitted.

There's a Django app (that I forget the name of) that disables lazy loading in templates, thus requiring you to load everything explicitly in the view.

I think there's a few 3rd party solutions like https://github.com/charettes/django-seal but I don't love the idea of using something that I assume is monkey patching Django code.

There is an ongoing effort to include back the equivalent in core [here](https://github.com/django/django/pull/17554)

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

#140

Post by za3faran »

jampekka wrote: post #127
DarkNova6 wrote: post #115

Earlier quoted context omitted.

This is not even a counter argument. We are talking ORMs here, not dependency injection frameworks. The Java equivalent to Django ORM would be Hibernate. It doesn't strike me that you know what Spring does, nor where its own features end.

The comment I replied to was to general development. And Spring is the most popular Java web framework (that it's called a "dependency injection framework" is kinda telling about the architectural ideology). I've had the misfortune to use both Spring and Hibernate professionally.

I used Java, python, and golang professionally, and the Java ecosystem (and yes, including the language) is far ahead of what the others offer on almost all important fronts, including readability, expressiveness, testability, introspection, etc. You just need to be a little bit disciplined - then again, that is always the case regardless of language/platform.
Post reply on HN