#34423 closed Cleanup/optimization (wontfix)
Migrations, UniqueConstraint lenght of identifier can be too long for Postgres/MySQL
Reported by: | Joel Shapiro | Owned by: | nobody |
---|---|---|---|
Component: | Migrations | Version: | 4.1 |
Severity: | Normal | Keywords: | migrations, unique_constraint, UniqeConstraint |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
When creating a new unique constraint it is quite easy with the interpolation of %(class)s to generate a very long name as identifier (name) of the constraint.
Postgres and MySQL both have limits on how long the name can be (63/64) characters, Postgres does allow for a longer name but it will be truncated.
Creating two names with the same first part will make it so that we have two identical identifiers and the migrations will not work.
An error like this will be thrown;
django.db.utils.ProgrammingError: relation "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" already exists
Change History (3)
comment:1 by , 20 months ago
follow-up: 3 comment:2 by , 20 months ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Type: | Bug → Cleanup/optimization |
Thanks for this ticket, however, I'm against this change. First of all it is backward incompatible. Constraints have been introduced in Django 2.2 and constraints with a name of length greater than 63 characters are valid on other databases (64 on MySQL, 128 on MSSQL, etc.). I agree that it is a inconsistency between constraints and indexes policy but still we need to be careful with introducing incompatibilities. See also a related ticket, #30614.
Please first start a discussion on the DevelopersMailingList, where you'll reach a wider audience and see what other think, and follow the triaging guidelines with regards to wontfix tickets.
comment:3 by , 20 months ago
Replying to Mariusz Felisiak:
Thanks for this ticket, however, I'm against this change. First of all it is backward incompatible. Constraints have been introduced in Django 2.2 and constraints with a name of length greater than 63 characters are valid on other databases (64 on MySQL, 128 on MSSQL, etc.). I agree that it is a inconsistency between constraints and indexes policy but still we need to be careful with introducing incompatibilities. See also a related ticket, #30614.
Please first start a discussion on the DevelopersMailingList, where you'll reach a wider audience and see what other think, and follow the triaging guidelines with regards to wontfix tickets.
Thanks for the fast response!
Yes, I agree. Not great to break compatibility. I'll close the PR.
PR; https://github.com/django/django/pull/16664