4 ms·

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 Subquer

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.

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.