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

81–90 of 144 posts

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

#81

Post by 9dev »

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.

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.

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

#82

Post by gniting »

KronisLV wrote: post #30
djeiejejejej wrote: post #19

Earlier quoted context omitted.

Same here, but IMO it is related to skill and experience. Once you get sufficiently familiar with some paradigm the training wheels can come off. “Raw” SQL is already an abstraction. Over time all the implicit magic will get on your nerves. Trying to shoehorn two completely different worlds into one abstraction is not worth it: you get to learn today’s untransferable funky ORM syntax and idiosyncrasies while losing s…

> I concede however that handling of SQL, the field names, the relations, is annoying. But it’s core to the problem you are probably solving (some form of CRUD). Plumbing is annoying but as a plumber I’d say get used to it instead of wishing to be dancer. It feels more like outsourcing said plumbing to someone that has done a lot of it in the past and will in most cases save you time, even if they won’t do everything…

> but typically then you have an escape hatch to have the query be in raw SQL while still mapping the outputs to whatever objects you need.

This is precisely why we introduced the "TypedSQL" feature in the Prisma ORM. For those who are interested in reading more on that: https://prisma.io/typedsql

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

#83

Post by nprateem »

ruthmarx wrote: post #45
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.

LLMs are not at a point where we should be treating them as a solution to any software engineering issue, period.

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.

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

#84

Post by nprateem »

9dev wrote: post #76
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…

I don’t really understand this, I was very much underwhelmed by the admin UI, and feel like I’m missing something? I mean what does it do other than list records and provide some basic forms to CUD those? It feels like much of the value in that is achieved even better by using a proper database client, say, JetBrains‘ database integration. I certainly wouldn’t let any business people touch a Django admin panel, or at…

It excels when you're iterating on an MVP. Once a business is proven and you have the money to go back and put in the the gold-plated solutions, sure, write your own. But while you're building the MVP it's amazing. No need to faff with building a separate admin, even if it is just CRUD.

It means you can focus on your business logic while buying time to get you through the initial development.

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

#85

Post by nprateem »

AmericanChopper wrote: post #47
rowanseymour wrote: post #39

Earlier quoted context omitted.

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.

I personally don’t think DB migrations are that difficult, and I’d say they can be done a lot safer without an ORM. I’ve also never found an ORM that was easier to learn and overall easier to use than SQL. I’ve never understood how ORMs became so popular, I don’t get how somebody can look at how opaque and complicated they are and conclude that learning an ORM is easier than just learning SQL.

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.

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

#86

Post by sgarland »

jampekka wrote: post #65
eru wrote: post #63

Earlier quoted context omitted.

ORMs are a bad idea in the first place: relations are a great way to organise your data, why would you want to sully that by converting to something object oriented? > 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. To give a nice counterexample: Python…

> ORMs are a bad idea in the first place: relations are a great way to organise your data, why would you want to sully that by converting to something object oriented? One big why is SQL. It's a horrible language/API but sadly practically all relational databases are SQL.

So horrible that it’s been the standard for 50+ years.

The relational model is great. Embrace it, because it isn’t going anywhere.

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

#87

Post by sgarland »

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…

> 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.

What? You have to understand a language to write performant code in it. That’s not a hack, that’s basic competence.

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

#88

Post by jampekka »

sgarland wrote: post #86
jampekka wrote: post #65

Earlier quoted context omitted.

> ORMs are a bad idea in the first place: relations are a great way to organise your data, why would you want to sully that by converting to something object oriented? One big why is SQL. It's a horrible language/API but sadly practically all relational databases are SQL.

So horrible that it’s been the standard for 50+ years. The relational model is great. Embrace it, because it isn’t going anywhere.

Relational model is good, SQL is not. They are not the same thing.

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

#89

Post by sgarland »

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.”

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

#90

Post by raziel2p »

ebcode wrote: post #40

Anytime I hear ORM, I always think of this: https://blog.codinghorror.com/object-relational-mapping-is-t...

I tried reading and understanding the arguments made here, but just could not make any correlation with my day to day experience using ORMs.

is it possible that the fact this article is written in 2006 simply makes it dated? it seems very catastrophizing but we've come a long way and are just more aware of how to work with or around the shortcomings and flaws of ORMs.

I've often written programs where I'm trying to encapsulate pure in memory state into business objects and run into the same type of issues people complain about with ORMs. programming is just hard, we don't have to be such dogmatists about it.

Post reply on HN