The ORM is great ... but is a question of taste/previous experiences. Once you start playing with annotations, DB-side functions and subqueries, it is very nice.

Only frustration I have is the power/possibilities of mysql (which I use 99% of the time for various reasons) versus postgre. The latter seems far better and advanced, and it does reflect in the ORM.

But wait, this isn't linked to django, is it? :-)

I agree. I can generally do what I need to with the ORM, except in extreme cases where you probably should be writing custom SQL anyway. I do fight with Subquery and OuterRef now and then, thinking OuterRef isn't being used in a Subquery when it is, but a little debugging usually resolves that.

The one thing I really wish Django had after all these years is multi-column PK support. I bring it up every time I see a thread about Django, hoping the devs or an open-source contributor will take it on. But after 10+ years, the open ticket just keeps passed on and I don't know that I have the skills to do it myself.

care to elaborate on that "multi-column PK support" please? :)

:)

Django currently requires that every table have a _single_ primary key column. You can have a unique multi-column index, but you _also_ need to have a single primary key column, which sometimes makes working with existing databases tricky or inefficient.

It's Django's oldest open ticket, from August 2005: https://code.djangoproject.com/ticket/373

The trick is how do you group those columns together in a way that stays compatible with the rest of the framework.

Here's a 2015 proposal "DEP 191" for how to make it work:

- https://github.com/django/deps/blob/main/draft/0191-composit...

Basically, the multi-columns end up needing to be exposed as a single python object (CompositeField) to stay compatible with the rest of the framework, but do changes to the individual "subfields" on the row-object need to be kept in sync (data binding) with the CompositeField-object and maybe vice-versa? Now we need an "Observer" (which Django doesn't currently have) to watch for changes to fields, etc. So a lot of new concepts end up needing to be introduced to make this happen. And it needs to work with migrations and serialization while trying to maintain backward-compatibility.

Here's rough code (again, from 2015):

https://github.com/django/django/pull/4553

Since 2015, Django now has class-based-indexes which should make things slightly easier:

https://docs.djangoproject.com/en/stable/ref/models/indexes/

Maybe at least the Observables could get merged in as a first-step which would make the remaining work a little easier?

Great explanation. Thanks for taking the time to write it up and link to relevant posts. Any exposure can only help.

I see, what a hoot! :-)

That might be a matter of taste, or which ORM you've used previously. Personally I think it's the only sort of okay ORM, besides Go's sqlx, which is barely an ORM.

You do need to have the documentation handy, and writing efficient queries can be tricky, but it is the ORM that makes the most sense to me, and the easiest to get started with.

Have you tried SqlAlchemy? I liked that it felt a lot more like writing sql, whereas Django feels like trying to force a different model on top.