3 ms·

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

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? :-)

WesleyJohnson 5y ago
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.
- louissan 5y ago
  care to elaborate on that "multi-column PK support" please? :)
  - collinmanderson 5y ago
    :) 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 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-composite-fields.rst 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 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/ 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?
    - louissan 5y ago
      I see, what a hoot! :-)
    - WesleyJohnson 5y ago
      Great explanation. Thanks for taking the time to write it up and link to relevant posts. Any exposure can only help.

WesleyJohnson 5y ago

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.

louissan 5y ago
care to elaborate on that "multi-column PK support" please? :)
- collinmanderson 5y ago
  :) 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 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-composite-fields.rst 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 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/ 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?
  - louissan 5y ago
    I see, what a hoot! :-)
  - WesleyJohnson 5y ago
    Great explanation. Thanks for taking the time to write it up and link to relevant posts. Any exposure can only help.