Slash in constraint name results in invalid migration file naming

[Simon Dupouy]

Steps to reproduce:

1. create a model

   class TestModel(models.Model):
       foo = models.TextField()
       bar = models.TextField()
   

2. make and apply the initial migration
3. add a constraint with a forward slash in its name

   class TestModel(models.Model):
       foo = models.TextField()
       bar = models.TextField()
   
       class Meta:
           constraints = [
               models.UniqueConstraint(fields=['foo', 'bar'], name='foo/bar unique')
           ]
   

4. makemigrations and migrate

Result

Django tries to create a migration file named 0002_testmodel_foo/bar unique.py.
This results in the creation of the file bar unique.py in the directory 0002_testmodel_foo.
Hence, the last migrate command doesn't work.

Expected behavior

Creation of a migration file with a sanitized name, or a warning that the constraint name shouldn't contain special characters.

Remark

All that the documentation says on constraint names is

BaseConstraint.name
The name of the constraint. You must always specify a unique name for the constraint.

It isn't stated that the naming of constraints must follow specific conventions.

[Mariusz Felisiak]

Duplicate of #30614.

Different databases have different policies for constraint and index names. I don't think it's worth the additional complexity as databases throw a clear error for invalid names.

[Dustin Wyatt]

I think that this never gets to the database for the database to give an error...right? If I'm correct, I'm not sure what the appropriate fix is (if any). I'm not sure that "databases give good error messages for this problem" is a good resolution to a problem that databases do not give good error messages for.

[Simon Dupouy]

Replying to Dustin Wyatt:

I think that this never gets to the database for the database to give an error...right? If I'm correct, I'm not sure what the appropriate fix is (if any). I'm not sure that "databases give good error messages for this problem" is a good resolution to a problem that databases do not give good error messages for.

Indeed you are correct, the problem is in the way the makemigrations command finds a name for the migration file. Hence it is not exactly a duplicate issue in my opinion.

[Mariusz Felisiak]

Right, so it's a duplicate of #34050 (fixed in Django 4.2).