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
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
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,
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
I agree this feature would be useful, at least to allow bundling check
constraints with custom field classes. As you point out the
PositiveIntegerField classes do this within Django, and doubtless many
custom fields have used the db_check() method.
The only thing I'm not a fan of in your proposal
Hi folks,
We've had check constraints for a while now and they're awesome.
I'd like to propose an alternative way to declare check constraints: at the
field level. This sounds like it's duplicating the feature but there are
some advantages that make this distinct from declaring at the model-level
