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 sky.duv...@moveon.org 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/primary$20keys
> |sort:date/django-developers/wakEPFMPiyQ/ke5OwgOPAQAJ
