Small clarification here. > it should be noted that SQL has both CHECK on the field and table level,
>From my understanding CREATE TABLE / ADD COLUMN checks on the field level are really just syntactic sugar for checks at the table level like just like `REFERENCES` usage is syntactic sugar for foreign key constraints. > This is not true for unique constraints or indices. Unique constraints can be defined using the UNIQUE keyword just like CHECK is used to define a check per field, it's really just a different way of defining that a unique constraint on a field must be created. The question of whether or not we want to provide some Django syntactic sugar in the form of `Field.check` and the benefits it might provide to third-parties (and even ourselves for dog fooding PositiveIntegerField) remains but I think that it's important to point out that there's no distinction between field and table level constraints at the database level AFAIK (for Postgres and SQLite at least). Simon Le jeudi 6 avril 2023 à 01:47:48 UTC-4, Adam Johnson a écrit : > Mariusz, I agree with the burden, but it should be noted that SQL has both > CHECK on the field and table level, and CheckConstraint only defines > table-level constraints. This is not true for unique constraints or indices. > > Also, what do you think of a way for custom field classes to add > constraints, at least? db_check() is somewhat limiting given it must return > raw SQL, plus it's undocumented. > > On Thu, Apr 6, 2023 at 5:11 AM Mariusz Felisiak <felisiak...@gmail.com> > wrote: > >> Hi, >> >> This proposal is not really nice from a maintenance point of view as we >> will end with the same complicated situation we currently have with >> uniqueness checks or indexes i.e. many ways to define the same: >> >> - Field.unique/index >> - Meta.unique_together/index_together >> - Meta.constraints/indexes >> >> It's especially error-prone in migrations and different database behavior >> on fields already covered by the same constraints/indexes. I'm pretty sure >> that we've introduced Meta.contraints/indexes to avoid this happening in >> the future, and we are rather leaning to leave only >> Meta.constraints/indexes and remove other options in the future. Not >> creating a new one. >> >> Initial -1 from me. >> >> Best, >> Mariusz >> >> -- >> > 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 django-develop...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/954af838-2176-4877-b4ac-70525cddcbf5n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/954af838-2176-4877-b4ac-70525cddcbf5n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/58ab388c-2852-4e23-94b9-c4f7d9fa61bfn%40googlegroups.com.
