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

61–70 of 85 posts

Re: Django: One ORM to rule all databases

#61

Post by fatbird »

cies wrote: post #39
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 disagree to a point that I wrote an article about it. https://dev.to/cies/the-case-against-orms-5bh4 > Most times ORMs are fine, sometimes they are not. When fine is defined as "improves dev't speed" I think they are not "fine" for any serious (say 100kLOC+ size) project. > It's not a law or a prescription. They come with a lot of webFWs, to the point that a lot of web software is built on top of them. These FWs (D…

I worked on the pokemon.com website for several years. It has over 2 million LoC in python (~2.5 once you add in frontend JS). It's a Django site that uses Django's ORM; I can't recall ever seeing any raw SQL. As you might imagine, the site has high traffic and high performance requirements. We never found the ORM layer to be either a hindrance or a performance barrier.

Re: Django: One ORM to rule all databases

#62

Post by sillywabbit »

lelanthran wrote: post #54
bakugo wrote: post #46

Earlier quoted context omitted.

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

> They are an abstraction to map the data in your database to objects in your code and vice versa. Maybe that's part of the problem - you're trying to map tabular data in your database to hierarchical data in your programming language. Of course there's going to be all kinds of pain when pounding square pegs into round holes. Getting a better hammer (i.e. a better ORM) isn't necessarily going to help.

You're working with bits. It's turtles all the way down.

Re: Django: One ORM to rule all databases

#63

Post by taffer »

fatbird wrote: post #61
cies wrote: post #39

Earlier quoted context omitted.

I disagree to a point that I wrote an article about it. https://dev.to/cies/the-case-against-orms-5bh4 > Most times ORMs are fine, sometimes they are not. When fine is defined as "improves dev't speed" I think they are not "fine" for any serious (say 100kLOC+ size) project. > It's not a law or a prescription. They come with a lot of webFWs, to the point that a lot of web software is built on top of them. These FWs (D…

I worked on the pokemon.com website for several years. It has over 2 million LoC in python (~2.5 once you add in frontend JS). It's a Django site that uses Django's ORM; I can't recall ever seeing any raw SQL. As you might imagine, the site has high traffic and high performance requirements. We never found the ORM layer to be either a hindrance or a performance barrier.

Before the invention of SQL, people wrote software using VSAM files and navigational databases with extremely limited computing and memory resources and it worked.

That isn't the point, though. Some people, myself included, find that processing the data in a declarative language directly in the database makes your code simpler and less prone to bugs.

Re: Django: One ORM to rule all databases

#64

Post by gitaarik »

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.

The way it integrates into Django is more than just an abstraction to SQL. It's also an abstraction to your table schema, mapped to your model. In short, it's the Pythonic way of fetching data from your models in Django.

It allows for functional programming, as in building queries upon other queries. And predefined filters, easily combining queries, etc. And much more.

Of course you don't need all of that. But in a big project, where you might query some particular tables a lot of the times, and there are common joins you make between tables, then sometimes it is nice to have predefined models and columns and relations, so you need less verbosity when building the queries.

You do of course need to learn a new tool to build queries, but it does pay off in some cases.

Re: Django: One ORM to rule all databases

#65

Post by Backslasher »

c03 wrote: post #31
Backslasher wrote: post #10

Is Django's ORM even supported outside Django sites? I had a consulting gig that had a FastAPI website using Django's ORM and it produced a bunch of weird bugs.

> outside Django sites What does that mean? Like you can't use the library's ORM without exposing a webserver?

More like "on a long-running process that is not a full-blown Django server"

Re: Django: One ORM to rule all databases

#66

Post by JodieBenitez »

dvdkon wrote: post #59
JodieBenitez wrote: post #4

Earlier quoted context omitted.

I prefer working with Django ORM too by a large margin. But I think it's more opiniated than SQLAlchemy, which may be why SQLAlchemy is considered the reference (well.... this and the fact that Django ORM is not a standalone lib). It's great if your use case fits to it but if not, SQLAlchemy probably gives you more adaptability. But yes, Django ORM any day... or just no ORM at all.

SQLAlchemy has one strongly-held opinion, that there should be a 1:1 mapping between objects in a database and in memory. So if you query the database then modify the result, the change will automatically also be made in the DB. I strongly dislike this, since you always have to be careful not to make some unwanted change. When checking permissions, you have to check before you modify the object. You can't modify it a…

Last time I used it you had to commit session, so no actual change in the database is made until this. It's sill annoying that an update is scheduled though.

Re: Django: One ORM to rule all databases

#67

Post by leetrout »

sgarland wrote: post #50
sonthonax wrote: post #40

Earlier quoted context omitted.

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.

That's fair. Especially in environments in 2025 where it's common to only care about a DB URL for the app config and pretty much never manually jump into the DB.

I run into this with lots of tools and I just shrug and move on... I've actually never given this a second thought until you pointed out this inconsistency.

Re: Django: One ORM to rule all databases

#68

Post by izacus »

lelanthran wrote: post #28
izacus wrote: post #23

Earlier quoted context omitted.

Being closer to SQL in my projects meant that it had more footguns than C++ and developers had to know a lot about DB details to not break things.

The only footgun is pretending that using an ORM means not having to learn SQL.

That's not what I said though.

Re: Django: One ORM to rule all databases

#69

Post by izacus »

bbkane wrote: post #24
izacus wrote: post #23

Earlier quoted context omitted.

Being closer to SQL in my projects meant that it had more footguns than C++ and developers had to know a lot about DB details to not break things.

I don't think it's unreasonable that devs should have to learn about database details to correctly use a database. Could you list some specific examples where things broke because of SQLAlchemy's design?

Managing connections, connection looking and transactions was something that was always an issue with SQLalchemy for us. Migrations were significantly more terrible as well.

Re: Django: One ORM to rule all databases

#70

Post by x0ff »

fdomingues wrote: post #51
Backslasher wrote: post #10

Is Django's ORM even supported outside Django sites? I had a consulting gig that had a FastAPI website using Django's ORM and it produced a bunch of weird bugs.

I have made this tiny module to use it wherever I want it. https://github.com/domingues/djangify-package

nice!
Post reply on HN