#32726: Enforce database level constraints for fields with limited choices
-------------------------------------+-------------------------------------
Reporter: Eerik Sven Puudist | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: validation database | Triage Stage:
constraints | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Nick Pope):
I have a few comments:
> To prevent such a inconsistent state, I propose that one of the
following restrictions would be implemented (the choice might be database
specific):
If we were to implement something, we'd be unlikely to use different
approaches for different databases.
> - add a CHECK constraint to the field which would ensure that the value
falls into the range of acceptable choices
While this could theoretically be done, it does mean we'd be adding
migration operations for changes to `.choices` which previously generated
no operations. To avoid suddenly generating migrations for all existing
fields with `choices` we'd need to make this opt-in. I'm not sure if that
limits the usefulness somewhat.
It also add other complications - removal of a choice would cause an error
when applying the migration if the existing values were not changed in
advance. On large tables this can also trigger a revalidation of the
constraint which could be prohibitively expensive.
> - use the enum datatype to declare acceptable choices
Not all of the built-in database backends support `enum` types, e.g.
SQLite. There are also complications around management of changes to these
types if items need to be added or removed. It also requires new
operations in the database.
> - create an auxiliary table to store the acceptable choices and add a
foreign key constraint to the field
This is already possible manually by creating a `ForeignKey` manually.
----
Of all these options, I think the `enum` type isn't really viable. The
auxilliary table can already be done manually without adding unnecessary
complexity to Django to handle this. The `CHECK` constraint approach
perhaps could be considered, but would require careful thought. I'd
suggest taking this to the DevelopersMailingList.
--
Ticket URL: <https://code.djangoproject.com/ticket/32726#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.d00ec76421e026e5247e4b5a46a4a4b3%40djangoproject.com.
