Handle CheckConstraint.check -> condition.
Review Request #14743 — Created Dec. 22, 2025 and updated
Django 5.1 renamed the
checkargument/field insideCheckConstraint
tocondition, and 6.0 removed thecheckargument entirely. This
change adds a support flag and conditions to handle these updates. The
ChangeMetaandConstraintSignatureobjects have been updated to
normalize old evolutions and signatures appropriately.
Ran unit tests.
| Summary | ID |
|---|---|
| nnsntwsplxpzozktqypmupvyxlqxrqyn |
| Description | From | Last Updated |
|---|---|---|
|
) should be on the next line, with a comma on this line. |
|
|
|
This can be one statement. |
|
|
|
This can also be one statement. |
|
|
|
These, too. |
|
|
|
) should be on the next line, with a comma on this line. |
|
|
|
This can be one statement. |
|
|
|
line too long (81 > 79 characters) Column: 80 Error code: E501 |
|
|
|
As we type things, we'll need to make a decision on whether the classes own the arguments going in, or … |
|
|
|
This should probably use is. |
|
|
|
Instead of the del, you can use .pop(). |
|
|
|
This should probably use is for comparison. |
|
|
|
This is missing a Version Added. |
|
|
|
We do this a lot. We may want to just have a global. |
|
- Summary:
-
Handle CheckConstraint.check -> conditionHandle CheckConstraint.check -> condition.
- Description:
-
Django 5.1 renamed the
checkargument/field insideCheckConstraintto condition, and 6.0 removed thecheckargument entirely. This~ change adds a support flag and conditions to handle these updates. ~ change adds a support flag and conditions to handle these updates. The + ChangeMetaandConstraintSignatureobjects have been updated to+ normalize old evolutions and signatures appropriately. - Commits:
-
Summary ID nnsntwsplxpzozktqypmupvyxlqxrqyn nnsntwsplxpzozktqypmupvyxlqxrqyn
- Commits:
-
Summary ID nnsntwsplxpzozktqypmupvyxlqxrqyn nnsntwsplxpzozktqypmupvyxlqxrqyn
Checks run (2 succeeded)
-
-
As we type things, we'll need to make a decision on whether the classes own the arguments going in, or if those values should be untouched.
My feeling is they should be untouched, so the definitions don't have any side-effects.
In that case, we'd need to make sure we copy
new_valuebefore modifying it.If we don't go that way, we need to make sure we document that the argument may be modified by this class.
-
-
-
-
-