Migrations crashes with long identifiers on MySQL.

[Awais Qureshi]

I am trying to upgrade the project from django22 to 32.
Migrate command gives me this error

django.db.utils.OperationalError: (1059, "Identifier name 'blackboard_blackboardlearnerassessmentdatatransmissionaudit_chk_1' is too long")

I did't find any information related to this change in django32 release notes.

Important point: class BlackboardLearnerAssessmentDataTransmissionAudit(models.Model) is model name and app name is blackboard also.

[Mariusz Felisiak]

Thanks for this report, however I don't think you've explained the issue in enough detail to confirm a bug in Django. blackboard_blackboardlearnerassessmentdatatransmissionaudit_chk_1 is longer than the maximum identifier name on MySQL. Are you using the built-in backend for MySQL? Can you provide a minimum project to reproduce?

I didn't find any information related to this change in django32 release notes.

Have you checked release notes for Django 3.0 and 3.1?

[Awais Qureshi]

I am using mysqlclient==2.0.3 and all django defaults packages/backends.

Yes I have checked django30 and 31 release notes, but no information available with this change. Same migration is working fine in django22.

blackboard_blackboardlearnerassessmentdatatransmissionaudit_chk_1 it has 65 characters but seems fine with django22.

[Mariusz Felisiak]

... it has 65 characters but seems fine with django22.

This error is not raised by Django, but by MySQL. Can you provide a minimum project to reproduce?

[Jacob Walls]

Have you verified the model field referred to is still in your project? I can produce your error if I'm executing a previously written migration but where the field is no longer in my project. Instead, if the field is in my project, I get this upon migrate:

SystemCheckError: System check identified some issues:

ERRORS:
x.xxxx: (models.E018) Autogenerated column name too long for field "blackboard_blackboardlearnerassessmentdatatransmissionaudit_chk_1". Maximum length is "64" for database "default".
        HINT: Set the column name manually using 'db_column'.

This system check predates 2.2, so if the field is in your project and no system check is raised, that would be a false negative to address. But we would need a minimal project to verify that the field exists.