31–40 of 85 posts
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.
What does that mean? Like you can't use the library's ORM without exposing a webserver?
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'm one of the biggest fan of the Django ORM and I wish it would have won the battle over alembic/sqlalchemy that I dislike
But why? Although I have way more experience with Django ORM, I find that SQLAlchemy is closer to SQL and I have to think less how to express complex queries. With Django ORM changing a few characters can change resulting query from LEFT JOIN to INNER JOIN, for example. I find it more difficult to write complex queries in Django ORM.
I dislike all ORMs, but I especially dislike SQLAlchemy for its hideously bad docs.
[flagged]
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.
I like my ORMs based on SQL concepts, not OOP concepts.
So you do have to know SQL, but you get more convenient ways of generating it.
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.
what's the purpose of this blog post? "My goal is to help you see quickly where each database works well and where it has some limits. I also hope this can be useful for anyone who wants to improve Django, or just understand it better." OK, then I look at the feature matrix and see a lot of obvious errors, then I see: "The data in the table below is entirely fictional and intentionally provided only for example! I in…
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.
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 (Django, Rails, Laravel, Symfony, Play, etc.) promote the use of ORMs.
Earlier quoted context omitted.
SQLAlchemy was just more expressive in previous years and was a requirement for projects that had more advanced data types and didn't want to use raw sql (or build their own ORM pieces). Django is sealing its fate with the opposition to type annotations. I hope sqlc continues to grow on the Python side because it is wonderful in Go. alembic is also much better than Django's migrations for the ability to expose the tr…
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.