This is good. It would be nice to include MSSQL even though its third party (it doesn't support distinct on columns which was a suprise).
Django: One ORM to rule all databases
71–80 of 85 posts
Re: Django: One ORM to rule all databases
#72Earlier 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…
I was going to say this. To eschew types means a bunch of attrs boilerplate to include it if you aren’t doing pydantic. sqlalchemy is just better suited for getting the job done using a pretty standard interface from other orms. The multi “app” structure is confusing as hell to someone who is writing an… app. It reminds me of JBOSS from Java and no one likes JBOSS app servers anymore.
The multi app structure is really good and enables extending your project with other apps and gaining all their migrations and everything else.
Its one thing I didnt appreciate until I tried fastapi and found it wasn't there.
Re: Django: One ORM to rule all databases
#73Earlier quoted context omitted.
Mostly, I think, the problem is SQL injection, and raw SQL is a great place for people to forget to escape their strings.
ORM's are not the only solution to SQL injection, pyscopg for example handles string escaping etc for you.
Yeah, if you remember to use it properly. SQL injection was pretty rampant before ORMs and web frameworks started being used everywhere.
ORMs let anyone make CRUD apps without needing to worry about that sort of thing. Also helps prevent issues from slipping through on larger teams with more junior developers. Or, frankly, even “senior” developers that don’t really understand web security.
Re: Django: One ORM to rule all databases
#74Earlier quoted context omitted.
I was going to say this. To eschew types means a bunch of attrs boilerplate to include it if you aren’t doing pydantic. sqlalchemy is just better suited for getting the job done using a pretty standard interface from other orms. The multi “app” structure is confusing as hell to someone who is writing an… app. It reminds me of JBOSS from Java and no one likes JBOSS app servers anymore.
The multi app structure is really good and enables extending your project with other apps and gaining all their migrations and everything else. Its one thing I didnt appreciate until I tried fastapi and found it wasn't there.
Agree to disagree.
I’d rather utilize requirements.txt or pyproject.toml to include a library than add an app to my app.
No. I refuse to operate like Wordpress. Glad it’s fine for you but it doesn’t with me for a variety of reasons. The biggest being is now you have multiple apps running in your app so who is to blame when it fails? You? The inner app provider? Django? Accounting? When utilizing libraries, we can utilize testing that can test our code against them either directly or using mocks. Separating ourselves from our dependencies, in case our dependencies change. Django’s model would have you add apps on apps with model definitions spread all over the code base making it near impossible to tell what your schema is…
The JBOSS App Server model is so dead. If I had it my way, Django would be deprecated in favor of FastAPI, Pydantic, and SQLAlchemy.
Re: Django: One ORM to rule all databases
#75Earlier quoted context omitted.
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.
How? Stored procedures?
I find that to be insane.
How do you version that code, and how do you reason with the business logic split all over the DB and code?
Re: Django: One ORM to rule all databases
#76ORMs 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.
The problem with ORMs is that they're a very leaky abstraction. Database performance matters a lot for any non-trivial application, and in order to use an ORM performantly you need to understand both the underlying SQL+database but also all of the nuances of how the ORM maps to SQL.
So basically you end up with two situations:
1. You need to hire engineers with double the expertise (not just a SQL engineer, but a SQL+ORM engineer).
1a. You hire a SQL engineer who now has to learn Yet Another ORM.
2. You hire engineers who only know the ORM but not SQL, and your app ends up having shit performance.
Basically, ORMs are simply complicated SQL generating macro frameworks. They are way too leaky to provide a useful level of abstraction like most programming languages.
LLM coding tools may displace ORMs, because they can take away a lot of the tedium with integrating application SQL, which is what ORMs are supposed to do.
Re: Django: One ORM to rule all databases
#77Earlier 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.
I cannot imagine a 2MLOC codebase with rdbms persistence that does not need custom SQL. I believe you, but I also think that's a special case.
Re: Django: One ORM to rule all databases
#78Earlier quoted context omitted.
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.
How? Stored procedures? I find that to be insane. How do you version that code, and how do you reason with the business logic split all over the DB and code?
> How? Stored procedures?
Not neccesarily. jOOQ[1] and sqlc[2] are great options if you don't like stored procedures, but for a small app or a prototype, just having plain SQL strings in your app is fine.
My point isn't that the code has to be stored in the database, but rather that the processing happens in one place where your data is stored and your middle tier just gets the results. Pure, stateless data. This means you don't have to synchronise shared mutable state between your app and your DB server, cutting out all the headaches of ORMs, such as having to specify your data model in two separate places, n+1 queries, locking, lifecycle management, dirty tracking, eager loading, caching, and optimistic concurrency control. All of this adds to complexity and congnitive load.
SQL also provides a declarative approach to defining your business logic. You define the what, not the how. In addition to greater productivity, the programming model is much simpler because you aren't complecting control flow with data flow. With JSON support in Postgres, your query results don't have to be flat tables either. You can get your data in the exact shape you need.
> How do you version that code
You put it into your VCS. SQL is part of your code base, you can and should version control it just like any Python, Ruby or Java code. When using stored procedures, I recommend putting them in a separate schema, so that the schema can be dropped and recreated in a single transaction during deployment. See [3] for an example of stored procedures under version control.
> how do you reason with the business logic split all over the DB and code
You separate your concerns instead of mixing them. The core business logic is in SQL, with your middle tier doing the plumbing, orchestration of external services and presentation.
Re: Django: One ORM to rule all databases
#79Footnote: 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)…
For many people, it's a gateway to back-end development. You don't have to learn all those weird, ancient tools, you just write a bit of Python. Look at this simple example! And then they get stuck on it.
Re: Django: One ORM to rule all databases
#80Earlier quoted context omitted.
How? Stored procedures? I find that to be insane. How do you version that code, and how do you reason with the business logic split all over the DB and code?
> How? Stored procedures? Not neccesarily. jOOQ[1] and sqlc[2] are great options if you don't like stored procedures, but for a small app or a prototype, just having plain SQL strings in your app is fine. My point isn't that the code has to be stored in the database, but rather that the processing happens in one place where your data is stored and your middle tier just gets the results. Pure, stateless data. This mea…
I don’t get this at all, and I tried to understand it.
I'm good at SQL. When necessary (maybe once a year), I can drop into pure SQL instead of Django ORM like it's nothing.
The thing is, I can't imagine why I would ever want to.
All these anti ORM comments read like they want to be as close to the DB as possible.
This is not what I want. I don't care about guaranteeing the most efficient query, because it is never the bottleneck, not even close.
I want to be as expressive as I can be in the business logic, and I don't feel like I am using pure SQL.