Changing violation_error_message on constraints cause a remove/add operation in migration

[David]

Changing the violation_error_message of a constraint and running makemigrations causes the migration to be written with two operations RemoveConstraint and AddConstraint .

Suppose we start with this situation:

from django.db import models

class MyModel(models.Model):
    counter = models.IntegerField(defalt=0)
    max_value = models.IntegerField(defalt=0)
    name = models.CharField(max_length=4)

    class Meta:
        constraints = (
            models.CheckConstraint(
                check=models.Q(counter__gte=models.F('max_value')),
                name='counter_lower_than_max',
            ),
            models.UniqueConstraint(
                fields=('name', 'max_value')
                name='uniq_name_and_max',
            ),
        )

If we add a custom violation_error_message and run makemigrations it will output

$ ./manage.py makemigrations mysample -n update_violation_msgs
Migrations for 'mysample':
  mysample/migrations/0002_update_violation_msgs.py
    - Remove constraint counter_lower_than_max from model mymodel
    - Create constraint counter_lower_than_max on model mymodel
    - Remove constraint uniq_name_and_maxfrom model mymodel
    - Create constraint uniq_name_and_maxon model mymodel

This will cause the database tu run useless commands, since nothing on database side has changed!
This may be a particular problem when applied to UniqueConstraints since the database needs to destroy and re-create an index.

[David Sanders]

Thanks for the report 🏆

Aside from running useless commands, dropping & adding constraints on a production database may be undesirable.

[Salvo Polizzi]

PR: ​https://github.com/django/django/pull/17644

[Mariusz Felisiak]

Marking as needs improvement pending a discussion.

[Shubham Singh Sugara]

Hi team ,
Is anyone working on this i think another issue (ticket ) is also waiting for this to resolve (#35305)
willing to have a crack at it, open to dicussion
old PR closed with this comment on commit , maybe we can start from here , like what is the correct way to implement this patch ?
​https://github.com/django/django/pull/17644/commits/fe9fa7ff28abc5a5a5bd70b93a1d8452ec1b5332#r1435873636

[Jacob Walls]

I think the latest ​consensus is that we need a new Operation for AlterConstraint that is documented to be a no-op (emits no SQL) and that the migration framework will produce in these cases in order to avoid dropping and recreating constraints on the database.