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

Django: One ORM to rule all databases

paulox.net

Post reply on HN
Print view View original

41–50 of 85 posts

Re: Django: One ORM to rule all databases

#41

Post by materielle »

1a527dd5 wrote: post #32

ORMs are one of those topics that get hotly debated for little reason IMO. ORMs like almost everything else in SWE they are _tool_. It's not a law or a prescription. It's not mandatory. ORMs are fine for 99% of cases. When it isn't fine use raw sql, no one is going to mock you, no one is going to jeer at you. Most times ORMs are fine, sometimes they are not.

My problems with ORMs is that they are a solution in search of a problem most of the time.

We already have an abstraction for interfacing with the DBMS. It’s called SQL, and it works perfectly fine.

Re: Django: One ORM to rule all databases

#42

Post by cies »

brokegrammer wrote: post #29

I used to love the Django ORM when I didn't know any SQL. Then I had to learn SQL so that I could model data properly, and optimize access patterns. These days I hate working with the ORM because it uses weird abstractions that make your life harder as you try to do more complicated stuff with your data. I had a small bug lately where a queryset would aggregate twice because I filtered an aggregated queryset, and thi…

I used to love PHP until I wrote a lot of it and gained experience with a list of other languages, now I hate it.

And this is how we become experienced SWEs.

> use SQL directly instead of an ORM

Me too.

Re: Django: One ORM to rule all databases

#43

Post by pyuser583 »

I really, really love the Django ORM. We had some good times together, and we still occasional work together.

But at the end of the day, SQL is text. That's life. Sorry - i know it sucks.

I've fallen in love with lightweight frameworks like pypika.

Part of this is the fact that AI smoothes over the rough spots. I would hate to have do an extremely complex query - highly complex case statements with unusualy datatypes - in pypika without AI. But with AI it gets really easy.

More broadly, AI makes using low-level frameworks much more practical. Requests is on the way out, and the socket framework is back.

The Django ORM is still amazing, especially when it comes to speed and handling multiple different types of databases.

But if you want to do something like create soft deletes (including cascading), it get's really hard really fast.

Re: Django: One ORM to rule all databases

#44

Post by default-kramer »

1a527dd5 wrote: post #32

ORMs are one of those topics that get hotly debated for little reason IMO. ORMs like almost everything else in SWE they are _tool_. It's not a law or a prescription. It's not mandatory. ORMs are fine for 99% of cases. When it isn't fine use raw sql, no one is going to mock you, no one is going to jeer at you. Most times ORMs are fine, sometimes they are not.

I think the reason they get hotly debated is that people's personal experiences with them differ. Imagine that every time Alice has seen an ORM used it has been used responsibly, while every time Bob has seen an ORM used it has been used recklessly/sloppily. I'm more like Bob. Every project that I've seen use an ORM performs poorly, with select N+1s being the norm and not the exception.

Re: Django: One ORM to rule all databases

#45

Post by cies »

stuckinhell wrote: post #25

I like the ORM but Django has stagnated in so so many ways. Most of my startup friends basically use Ruby on Rails for their startup webap, and python microservices these days. If you know python (hate ruby) and like javascript well enough FastAPI and javascript frontends seems way better.

Used to prefer Ruby and Rails.

Now I think Kotlin is basically a "typed Ruby". And projects like http4k[1] and terpal-sql[2] make webdev't a rather blissful experience.

1: https://www.http4k.org

2: https://github.com/ExoQuery/terpal-sql

Re: Django: One ORM to rule all databases

#46

Post by bakugo »

materielle wrote: post #41
1a527dd5 wrote: post #32

ORMs are one of those topics that get hotly debated for little reason IMO. ORMs like almost everything else in SWE they are _tool_. It's not a law or a prescription. It's not mandatory. ORMs are fine for 99% of cases. When it isn't fine use raw sql, no one is going to mock you, no one is going to jeer at you. Most times ORMs are fine, sometimes they are not.

My problems with ORMs is that they are a solution in search of a problem most of the time. We already have an abstraction for interfacing with the DBMS. It’s called SQL, and it works perfectly fine.

> We already have an abstraction for interfacing with the DBMS. It’s called SQL, and it works perfectly fine.

ORMs are not an abstraction to interface with the DBMS. They are an abstraction to map the data in your database to objects in your code and vice versa. It's literally in the name.

Feels like a lot of anti-ORM sentiment originates from people who literally don't know what the acronym means.

Re: Django: One ORM to rule all databases

#48

Post by cies »

tgv wrote: post #13

Footnote: as long as it's SQL, you stick to hierarchical relations, have enough memory, and can write difficult queries by hand

> and can write difficult queries by hand

So now I have to learn an ORM (with some kind of lifecycles, dirty tracking, eager/lazy loading config, etc.)... aaaaand I have to learn SQL as well, because the ORM's abstraction is leaky.

I see some benefits in ORMs for deleting and updating tables. But the benefits are slim and the cost (learning a library that requires understanding of quite a list of additional concepts) are significant. Considering that on-top-of learning the ORM I also need a proper understanding of SQL (for complex t queries or debugging ORM inefficiencies), I'd say it's not worth it.

Re: Django: One ORM to rule all databases

#50

Post by sgarland »

sonthonax wrote: post #40
sgarland wrote: post #30

Earlier quoted context omitted.

Alembic cannot fake a migration, which is a continual source of pain for me at my current job. There are many migrations that I simply don’t trust development teams to do. The inability to easily tell Alembic to get over itself and trust that something has occurred is frustrating.

You just set the alembic version yourself in the alembic.version table. It’s not rocket science.

Yes, I know how to fix it. I’m saying that it’s absurd to have to drop down to SQL to get an ORM to play nicely; Django handles this with a flag.
Post reply on HN