Hi,
This would be useful for us too ; this is our use-case, again this is a
legacy schema which are rebuilding the system to use django, but there
are some models which we are using composite-pk support for due to the
following. Having these feature many we could use a vanilla django.(eg
one without local patches)
Many of the table in our system are effectively, what django refers to
a through table. Eg, the join table in a many-2-many relationship , or
more often then not multi-join. We almost always fetch by a a the
set of joined PKs and those have been used a composite primary key on
the table.
In this use case we are accepting not having admin tables as in many of
them are computed detail tables, but we still have uniqueness
guarantees at the SQL level since the Db still has the tables defined
with a PK.
Django's query builder as standard cannot interact with these tables,
adding this option will allow us to code model which partially capture
the semantics and build queries against them. I don't think we lose the
ability to use get() as there is still a uniqueness guarantee on the
table; it just it is partially hidden from the orm .
In some cases these are our largest tables with 10^7 or even 10^8 rows,
so adding an additional field is not undertaken lightly. We also have
an additional restriction in that the legacy code is still active is
some part of our system and still need to interact with these tables as
well.
I hope that might explain one way this option could be helpful.