#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: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Eerik Sven Puudist:
Old description:
> The following is based on PostgresSQL, but is applicable to other
> databases as well.
>
> When I define a `CharField`, for example this one from the official docs:
>
> `year_in_school = models.CharField(max_length=2,
> choices=YearInSchool.choices, default=YearInSchool.FRESHMAN)`
>
> a regular `VARCHAR` field will be defined in the database with no
> constraints preventing me from inserting other strings to it when I
> interact directly with the database bypassing the Django layer.
>
> This would compromise data integrity and lead to a state where an
> unforeseen string is stored in that field which the application would not
> be able to properly handle.
>
> To prevent such a inconsistent state, I propose that one of the following
> restrictions would be implemented (the choice might be database
> specific):
> - add a `CHECK` constraint to the field which would ensure that the
> value falls into the range of acceptable choices
> - use the enum datatype to declare acceptable choices
> - create an auxiliary table to store the acceptable choices and add a
> foreign key constraint to the field
New description:
When I define a `CharField`, for example this one from the official docs:
`year_in_school = models.CharField(max_length=2,
choices=YearInSchool.choices, default=YearInSchool.FRESHMAN)`
a regular `VARCHAR` field will be defined in the database with no
constraints preventing me from inserting other strings to it when I
interact directly with the database bypassing the Django layer.
This would compromise data integrity and lead to a state where an
unforeseen string is stored in that field which the application would not
be able to properly handle.
To prevent such a inconsistent state, I propose that one of the following
restrictions would be implemented (the choice might be database specific):
- add a `CHECK` constraint to the field which would ensure that the
value falls into the range of acceptable choices
- use the enum datatype to declare acceptable choices
- create an auxiliary table to store the acceptable choices and add a
foreign key constraint to the field
--
--
Ticket URL: <https://code.djangoproject.com/ticket/32726#comment:1>
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.41f6ee91cce78c9d08b724808fcce819%40djangoproject.com.
