News for hackers. Stuff that matters.
Re:Software development topics I've changed my mind on after... by globular-toast on Thursday February 06, 2025 @08:48AM (#42962252)
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?

Re:Software development topics I've changed my mind on after... by wimdetroyer on Thursday February 06, 2025 @10:23AM (#42963222)
>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,...

Re:Software development topics I've changed my mind on after... by Izkata on Thursday February 06, 2025 @09:11AM (#42962478)
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)
Re:Software development topics I've changed my mind on after... by globular-toast on Thursday February 06, 2025 @09:55AM (#42962931)
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.
Re:Software development topics I've changed my mind on after... by Izkata on Thursday February 06, 2025 @10:36AM (#42963355)
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...

Re:Software development topics I've changed my mind on after... by globular-toast on Thursday February 06, 2025 @02:18PM (#42965545)
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!