Will Django ever CompositePrimaryKeys?

[Lance Ellinghaus]

I have a number of legacy databases that I need to access from Django and they do not have a single field primary key. They have composite primary keys. There is no easy way to add the single field primary key because other programs create records and Django would not be the application that maintains and modifies these tables.

I asked about this on the Django Users list and Simone Federici said:

sincerely, nobody take care about that feature because that's needed just for legacy db. 

The number of applications with on legacy db is less than 0.01% of the django applications.

There are some workaround for that applications, for example use SQL Alchemy.

 

I implemented a CompositeKey Dajngo feature for Django 1.4.  It is completly working also for the Generic Keys, concatening escaped keys. There was also a draft to implement the indexes. However, Django core team is evolving the platform so quickly (good for the framework) and the library is not mantained anymore. On Dajngo 1.6 I had should rewrote it completly.

 

In the end, now I understand why the core team don't care about the feature. Forget it. 

Should I consider his statements to be the final statement from the Django core developers?

Thank you,

Lance Ellinghaus

[James Bennett]

On Tue, Feb 19, 2019 at 4:44 AM 'Lance Ellinghaus' via Django developers (Contributions to Django itself) <django-d...@googlegroups.com> wrote:

Should I consider his statements to be the final statement from the Django core developers?

You should take it as someone giving their opinion on the users list.

This is the current roster of "Django core":

https://www.djangoproject.com/foundation/teams/

As to your actual question, the main issues were also discussed in the thread:

* Someone sufficiently motivated needs to sit down and write the code and do it in a way that integrates well into Django

* That person needs to commit, or find someone willing to commit, to maintaining this code in Djano

To date, nobody has stepped up and complete those things. If you'd like to make an attempt because you need the feature, you're certainly welcome to, and I don't think anyone will try to stop you (there would almost certainly be constructive feedback on API design, but that's about guiding something to completion, not stopping it).

[Dan Davis]

James,

As a Django user I've had this problem often. My best practice ways to handle this is as follows:

• If the table is read-only, then create a database-level view that manufactures a primary key by concatenating the primary key columns together.   Lie to Django and say this combined column is the primary key, and keep the Database-level view's model as managed = False at the Django level.   However, keep the SQL for the view in your git repository, and when it changes, build a manual migration - manage.py makemigration fooapp --empty -n create_replace_bar_view.

• If the table is read-write, then either (a) create a view with instead of update/instead of insert triggers that manage an underlying table, or (b) just add a unique ID and make the existing primary key a unique together constraint and index.  With the trigger to add a new ID, other users of that table shouldn't notice any issues.

• Maybe my statement that Django should manage migrations to the schema seems unworkable. However, one of the biggest gains you can get from Django with old schemas like this is to get their DDL into git. Even if git doesn't do it, make sure some code does it, and it isn't left unmanaged. That's been a key challenge and opportunity for me.

As a Django developer, I'm a bit green to volunteer to handle this issue, but this is exactly the kind of issue that leads me to be a developer - I see the ORM and the all-bells included nature of Django as the killer combo.  I don't have to go outside the farm to have database migrations, url routing, etc.  It is almost all there.  So, please ping back in 3 months to see whether I'm up to it.

[Josh Smeaton]

To add - there's definitely appetite for this feature, but it's a difficult one, and no one has stepped up to do it.

There are DEP drafts that cover pieces:

https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst

https://github.com/django/deps/blob/master/draft/0192-standalone-composite-fields.rst

Citus Data was looking to sponsor development for this feature, and still, no one with the technical capabilities was willing (or able) to step up: 

https://groups.google.com/forum/#!searchin/django-developers/composite|sort:date/django-developers/wakEPFMPiyQ/ke5OwgOPAQAJ

I would strongly advise not just running off and attempting something on your own. Look over the previous attempts and DEPs, and then document your way forward either by editing the DEP, and by initiating a thread on this list.

Cheers

[Simone Federici]

Lance Ellinghaus wrote:

Should I consider his statements to be the final statement from the Django core developers?

of course not, I'm not a core developer.

:-) 

[Dan Davis]

Thanks, Josh. I will be cautious if I ever get to taking this on.