Hi Adam, Mariusz & Simon, > The only thing I'm not a fan of in your proposal is repeating the field name within the check expression, like "price" in > ... 8< ... > Perhaps we could support only a special name instead, like “self” or the shorter “f”?
I was thinking the same thing +1 I wanted to throw up the proposal to elicit ideas on this because I wasn't sure whether reserving a field name like this might've been the way to go 🤔 > but it should be noted that SQL has both CHECK on the field and table level and from Simon: > CREATE TABLE / ADD COLUMN checks on the field level are really just syntactic sugar for checks at the table level Simon is correct here in that checks at column & table level are both declarations for the same underlying mechanism (at least from what I've seen with Postgres & MySQL). > This proposal is not really nice from a maintenance point of view Felix if there was no maintenance headache would it sound like a good idea though? What if there was some way to make it work nicely? I was wondering what ways that could be achieved: - if you use db_check() then there's no migration state conflict; only potential conflict in the database which would be resolved with unique constraint naming. - as an alternative could it somehow then be syntactic sugar to add to meta.constraints? this would then have the benefit of automatically being added to validation. The catch is migrations would need to take the fact that fields could add to meta into consideration because from what I've seen it keeps track of the "original" user-defined meta options. On Fri, 7 Apr 2023 at 04:55, charettes <charett...@gmail.com> wrote: > 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 > <https://groups.google.com/d/msgid/django-developers/58ab388c-2852-4e23-94b9-c4f7d9fa61bfn%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/CADyZw-5r%3Dhvn4%2BZqfrQftWsXH7C_9cBNcBZYNprGJFnrXMJMFg%40mail.gmail.com.
