[Django] #34351: Slash in constraint name results in invalid migration file naming
Django
-------------------------------------+-------------------------------------
Reporter: sdupouy | Owner: nobody
Type: Bug | Status: new
Component: | Version: 4.1
Migrations | Keywords: constraint name
Severity: Normal | slash
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 1
UI/UX: 0 |
-------------------------------------+-------------------------------------
== Steps to reproduce:
1. create a model
{{{#!python
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
{{{#!python
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/34351>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Type: | Status: closed
Cleanup/optimization |
Component: Migrations | Version: 4.1
Severity: Normal | Resolution: duplicate
Keywords: constraint name | Triage Stage:
slash | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
-------------------------------------+-------------------------------------
Changes (by Mariusz Felisiak):
* status: new => closed
* type: Bug => Cleanup/optimization
* resolution: => duplicate
* easy: 1 => 0
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/34351#comment:1>
Django
-------------------------------------+-------------------------------------
Reporter: Simon Dupouy | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Migrations | Version: 4.1
Severity: Normal | Resolution: duplicate
Keywords: constraint name | Triage Stage:
slash | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/34351#comment:2>
Django
-------------------------------------+-------------------------------------
Reporter: Simon Dupouy | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Migrations | Version: 4.1
Severity: Normal | Resolution: duplicate
Keywords: constraint name | Triage Stage:
slash | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Simon Dupouy):
Replying to [comment:2 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/34351#comment:3>
Django
-------------------------------------+-------------------------------------
Reporter: Simon Dupouy | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Migrations | Version: 4.1
Severity: Normal | Resolution: duplicate
Keywords: constraint name | Triage Stage:
slash | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Mariusz Felisiak):
Right, so it's a duplicate of #34050 (fixed in Django 4.2).
--
Ticket URL: <https://code.djangoproject.com/ticket/34351#comment:4>