Update python and django versions to run against #30
Conversation
gherceg
force-pushed
the
gh/update-versions
branch
from
b3b4d5b
to
26133bc
Compare
gherceg
force-pushed
the
gh/update-versions
branch
from
26133bc
to
161a00b
Compare
In Django 4.2, the behavior of __invert__ on Q objects was optimized
to toggle the negated attribute on the existing Q rather than add
an AND operator that wraps the inner clause.
On Django 4.2:
> from django.db import models
> ~(models.Q(test=1) | models.Q(test=2))
<Q: (NOT (OR: ('test', 1), ('test', 2)))>
> models.Q(models.Q(test=1) | models.Q(test=2), _negated=True)
<Q: (NOT (AND: (OR: ('test', 1), ('test', 2))))>
The optimized version is functionally the same, but creates an
unnecessary migration. This commit changes the syntax used when
defining the constraint to preserve the current format defined
in the migration.
field_audit/models.py
Outdated
| @@ -216,10 +216,11 @@ class Meta: | |||
| constraints = [ | |||
| models.CheckConstraint( | |||
| name="field_audit_auditevent_chk_create_or_delete_or_bootstrap", | |||
| check=~( | |||
| check=models.Q( | |||
There was a problem hiding this comment.
Rather than changing this model code, could we change the migration code to use the ~ syntax?
Should verify that it does not change the migration SQL, and also that it does not cause Django 3.2 to want to create a new migration.
There was a problem hiding this comment.
I ran sqlmigrate on the existing migration and the autogenerated migration by Django 4.2 to compare.
Old
CHECK (NOT ((("is_create" AND "is_delete") OR ("is_bootstrap" AND "is_create") OR ("is_bootstrap" AND "is_delete"))))
New
CHECK (NOT (("is_create" AND "is_delete") OR ("is_bootstrap" AND "is_create") OR ("is_bootstrap" AND "is_delete")))
So the difference is just an extra parenthesis around the inner condition of the NOT, but is that enough of a difference to warrant not changing the existing migration file itself?
There was a problem hiding this comment.
Semantically that is no different. I think it would be fine to change the migration file if it does not cause Django 3.2 to want to create a new migration.
There was a problem hiding this comment.
Cool. See 0bb2fc9. I tested that makemigrations on both 3.2 and 4.2 does not result in a new migration being created.
|
I updated the branch rules to require |
Expand tests to run against more versions of python, and only run against LTS releases of django and django 5.0 pre-release.