Lance, 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. Il giorno lun 18 feb 2019 alle ore 09:28 'Ellinghaus, Lance J' via Django users <django-users@googlegroups.com> ha scritto: > NONCONFIDENTIAL // EXTERNAL > So, basically, Django will not be supporting Composite Primary Keys in the > future? > > Lance > > -----Original Message----- > From: django-users@googlegroups.com <django-users@googlegroups.com> On > Behalf Of Michal Petrucha > Sent: Monday, February 11, 2019 8:34 AM > To: Django users <django-users@googlegroups.com> > Subject: [External] Re: Composite Primary / Foreign Key support > > NONCONFIDENTIAL // EXTERNAL > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On Mon, Feb 11, 2019 at 01:08:41AM -0800, 'Lance Ellinghaus' via Django > users wrote: > > I have seen references to people adding the support of composite > > primary keys to Django for years, but it does not look like it has been > added. > > > > I have a number of legacy databases that I cannot add fields to but > > need to be able to be queried through Django. They are read-only tables. > > A number of the tables are also related through Composite Foreign Keys > > and I have seen some addons but not sure what is fully supported. > > > > I am trying to use Django 2.1.5. > > > > Any help or ideas would be appreciated, and saying "Add a field to > > your tables" is not an option. > > > > Thank you. > > Hi Lance, > > I haven't been on top of this in recent years, but let me try. > > When it comes to just composite primary keys, as long as you only need > read access, you might be able to get away with marking an arbitrary field > as the primary key. Using a non-unique field as the primary key would make > any writes to the database dangerous, but that's not your case here. > However, you also lose the invariant that filtering on the “pk” field alias > will match at most one row, which means the admin would probably be off the > table, too – since that assumes the “pk” is, in fact, unique, and the same > holds for any other package that makes use of “pk”. You should still be > okay in your own code, though. > > For composite foreign keys, there is nowadays a private, undocumented API, > ForeignObject, which is what ForeignKey builds on. The general > ForeignObject lets you specify multiple fields that make up the relation, > you should be able to find some examples in the test suite (there is a > foreign_object package in there). Keep in mind that this is an internal > API, so it might change without warning. > > Good luck, > > Michal > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAEBCgAGBQJcYXniAAoJEHA7T/IPM/kl8EAP/Rzaxqe0bDO6vkxb4/Mmmj5S > 62t6Cfm3VqqK6NxYjRXG904jKwDI4HMH1SAs5fdVMh9vf+VBj/S5bcIpQbesqXbh > wbkcIn+mmnfhLDaHOGunYqp76tscBJv/rtxJZaX5NRLp7OraCWtbjRBtiw1fJ/tl > iJD0HRIk9zn0pqyX8GjeAyM0UR+uL1wwrvz8Ur85ASsc8pFThTP6ZMQoaEIgo9D+ > HB3XfrhiOMd5Nb2SbjG4KCRe7alpFx83nuY53YVsv+8X+Nqp4Ndi7ch2Ni3jxxHf > R7qVJYsMp/l72CNb6KiT85sb6PwQyeVdvU78cXKjkIKDirskGgQIEW2OvK+ZXC3B > Aj4I+AMFXEKje8ITfW3/s/v+UNvVTNZHYC5NPZ6o50+YJFDoiwb0mpQMdUredWZk > nT2cYMgyPQA/XKN9w5vUCNbTebPG/AA7yCthXbOrHn9Xl+kICkXRjjl9fHRUs55Q > wgPqz0CFXPKaE+JFt/NABJzdSrki1y587GHsOb7hKFiQwS8DHU8WOMXkR3BGKEtN > q0gebcqKvVnjRwLLsBvB0h3uI/yifgBTp8G8/+tZ0WuNdongTe+yPzchxuRjgx10 > e70xtBjgsyCQGRB3CPsgR2UelQOtAEt8ZyYwyPF5sQYOvQg1xjcYp87FqfqflSTE > 6aQIMkXhKjKazmc/ew9F > =Ji5Z > -----END PGP SIGNATURE----- > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/20190211133426.GV10973%40koniiiik.org > . > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/5c6a6c98.1c69fb81.eb4fb.5c2cSMTPIN_ADDED_MISSING%40gmr-mx.google.com > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAKsNYuh5CTnGeLnVRWK%2BtK1k4PNLJzRX_10my%3DoM_jgwG3PLzw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
