The main problem is if you are not very careful it leaks its internals (ie. the relational model) into everything it touches. That's what the N+1 query problem is. Business logic shouldn't have to know that certain attributes will cause database queries. By carefully writing managers and having a rule to never use querysets anywhere else you can avoid it, but it requires everyone to understand this and all the Django docs and examples everywhere will just randomly drop a queryset into a view or do a `prefetch_related` because they know that some higher-level function is going to need access to that attribute (ie. coupling code together).

Ultimately Django just doesn't fully do the object-relational mapping. It maps single rows, but that's it. So it doesn't really support objects that contain lists or sets etc. Things like SQLAlchemy can actually map data from a relational database into plain old objects. Those objects can be instantiated (e.g. in tests) completely independently of the database. Notice how in Django you can't test anything without a database being present? Why do I need to store an object in a db just to test some method on an entity?

>That's what the N+1 query problem is. Business logic shouldn't have to know that certain attributes will cause database queries.

I really don't get these arguments because in some form or another, ALL abstractions are leaky.

Example:

A novice developer might write a @OneToMany in hibernate without knowing the internals of the abstraction, causing n+1 problems. Two paths forward:

1. blame the abstraction

2. Learn (some) internals of the abstraction in order to use it correctly: dont do eager fetching, use join fetches, ... ( There's also tooling like hypersistence optimizer, digma, jpabuddy that comes to mind)

And by that same logic, would you berate somebody writing 'plain SQL' which - when expected with the query plan - turns out to be a very unperformant query?

Again, two options:

1. blame the abstraction

2. Learn (some) internals of the abstraction: analyze the query plan, perhaps write some indexes,...

The default test runner creates the test database automatically yes, but you can create Django model objects without touching the database, just use the class like a constructor and don't save it: Person(name="Foo", age=30)

OK, now try that with my ridiculously simple TodoList example, e.g. `TodoList(items=["item", "item2"])`. You can't do it! Nor can you construct an empty list then add items to it etc.

This is how ArrayField works in the postgres-specific fields: https://docs.djangoproject.com/en/5.1/ref/contrib/postgres/f...

Or falling back to a more generic JsonField elsewhere: https://docs.djangoproject.com/en/5.1/ref/models/fields/#jso...

Well yeah, but you could have just used a document store at that point. If you start using JSON field you open up the problems with document databases (namely you can't really do many to many). In any case, postgres being awesome is something you get without any ORM!