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. On Tue, 2017-05-23 at 11:31 +0300, Shai Berger wrote: > Hi, > > Thank you for making this suggestion. > > It is my guess that allowing pk-less models will place quite a burden > on many > parts of Django, which assume a PK exists. There may also be other > solutions > to the problem you raise -- e.g. changing the legacy table to add a > PK, > perhaps while providing a pk-less view to any legacy systems which > need to > access it. > > In general, SQL database tables without any uniqueness guarantee are > an > antipattern, which I don't believe Django should support. The > question remains > how much such a feature can be made to contribute towards composite > keys. > > All in all, I would like to know more about your use case -- if you > are going > to have no get/delete, no Admin, no updating save, how exactly are > you going > to use these models? As you may be aware, since the Meta API > formalization, it > is possible to create pseudo-models which are good enough for many > purposes, > without changing Django and with much less strict adherence to "real" > models' > behavior. Perhaps that is the way to go? > > HTH, > Shai. > > On Monday 22 May 2017 21:50:07 [email protected] wrote: > > Hi, > > > > We have several legacy database tables that don't have primary > keys. With > > older versions of Django, we've hacked it by lying about a field > that was > > not a primary key but recent Django versions validate pks more > strictly. > > > > Some (but not all) of our legacy tables have multiple primary keys > -- i.e. > > are unique only across a few fields. This harks to the > CompositeField work > > and discussion [0]. > > > > But CompositeFields are not enough for us, some of our tables are > > essentially append-only, and have no uniqueness constraints across > any/all > > fields. It also seems like CompositeField has stalled several > times > > precisely because we are spiking to a very complex end goal. > > > > I'd like to propose, both as an incremental step to CompositeFields > and > > something useful in itself, a model Meta option for > `without_primary_key` > > -- if Meta.without_primary_key=True then it would turn off the > complaints > > during model validation, etc. One might object that things like > > get/delete/caching can't work with that model. However those > features > > can't be supported in tables without a primary key anyway. > > > > Incrementally, after without_primary_key is implemented/supported, > we could > > then add features for models without_primary_key but also has a > > Meta.unique_together value across some fields -- i.e. start trying > to > > support inheritance and/or ForeignKey references to those tables, > building > > up support. > > > > I've started looking at how deep a change this would be, and > believe it's > > pretty tractable. > > Before I get too involved with a DEP and PR, what do people think? > > > > /sky > > > > [0] Most recent thread: > > https://groups.google.com/forum/#!searchin/django-developers/primar > y$20keys > > |sort:date/django-developers/wakEPFMPiyQ/ke5OwgOPAQAJ > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1495730818.14823.13.camel%40gammascience.co.uk. For more options, visit https://groups.google.com/d/optout.
