Lance,
I can't speak for the core team, only inform you based on what I've
seen here and in other projects.
I suspect if there was a significant need across a number of users,
then enough work could be done by those that needed it and as long as
it was
1) fully functional,
2) had clean good code
3) the people who wrote where going to stay within the
community to support it
Then there is a chance a set of code written might get merged, I don't
however thing there is sufficient interest from the core team for them
to do the work themselves.
Those requirements are quite a high bar, I started on some code to do
this, for a project a few years ago and got a limited set of composite
key functionality working in my own tree, which was just about enough
for the project I was working on. So I do have some understanding of
what is needed, and how intrusive and can get.
My code was fine for reading and writing, but you couldn't use
ForeignKey Fields to traverse composite key relationships. Which has a
surprising number of corner cases. This was for Django 1.8 and isn't
compatible with later versions (unfortunately). On the other hand some
of the code changes in the ORM point at a better approach, than we
took.
So it possible, but someone will need to invest some time into it.
The only immediately helpfuly ideas I have are;
As your requirement is read-only if the data is static you could to create a
second database, with all the PK of the legacy database, and
then as single Pk field to that table, and access everything through a view of
a join the two tables.
Of course if another app is adding rows then you are a bit stuck, but if you
absolutely can't add a autonumber field to use as a fake PK, then there is not
a lot you can do. I've started adding single PK autonumber fields to legacy
databases now when I get this issue, and
making the old PK into a unique index. So far that has working and hasn't
broken my legacy apps.
If those are no good, either you can't use django or you going to need to
invest in understanding the ORMs internals.
HTH,
--
Roger Gammans <rgamm...@gammascience.co.uk>
Gamma Science
On Mon, 2019-02-18 at 08:26 +0000, 'Ellinghaus, Lance J' via Django
users wrote:
>
> ONCONFIDENTIAL // 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/1550510983.11519.20.camel%40gammascience.co.uk.
For more options, visit https://groups.google.com/d/optout.
