Models are Call and Client. Call has a ForeignKey to a
PositiveIntegerField on Client. I'm changing the type of this field to a
CharField, but django/mysql cannot drop or add constraints.
I found this issue: https://code.djangoproject.com/ticket/28305. I had
hoped I was still using a version of 1.11 that didn't include the backport
but unfortunately for me I did.
Before creating this ticket I also came across
https://code.djangoproject.com/ticket/30152 which is also related to my
initial findings. As
https://code.djangoproject.com/ticket/30152#comment:10 says, the internals
are checking for relations that might have constraints, but in 30152's and
my case it doesn't find the relation. As a result the foreign key
constraint isn't dropped resulting in the error:
{{{
django.db.utils.OperationalError: (1833, "Cannot change column 'code':
used in a foreign key constraint
'myapp_call_clientcode_907d4acf_fk_myapp_client_code' of table
'test_test.myapp_call'")
}}}
After either applying the patch
https://code.djangoproject.com/attachment/ticket/30152/testcase_and_rough_fix.patch
or simply (temporarily) removing related_name='+' I get past this
OperationError. Instead I am confronted with:
{{{
django.db.utils.IntegrityError: (1215, 'Cannot add foreign key
constraint')
}}}
From what I've read about MySQL constraints this is caused by the
different field types. Changing the type of the original field doesn't
change the type of the foreign key field and the constraint cannot be re-
added after dropping it.
I created a project on github: https://github.com/cpoppema/django-migrate-
constraint-bug, ignore the master-branch for now.
Branch with original issue: https://github.com/cpoppema/django-migrate-
constraint-bug/tree/cannot-change-column-used-in-a-foreign-key-constraint
Branch with issue without related_name='+': https://github.com/cpoppema
/django-migrate-constraint-bug/tree/cannot-add-foreign-key-constraint
Known workaround that I've come up with is:
run a migration to change ForeignKey on Call to PositiveIntegerField
run a migration to change the PositiveIntegerField on Client to CharField
run a migration to change the PositiveIntegerField on Call to ForeignKey
With this, both fields end up as a CharField. I'd rather have Django
generate either multiple migrations or do an ALTER TABLE for related
fields.
--
Ticket URL: <https://code.djangoproject.com/ticket/30591>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* version: 2.2 => master
* stage: Unreviewed => Accepted
Comment:
Thanks for detailed report. #30152 is related but it doesn't fix the main
issue. I attached tests for both scenarios.
Reproduced at 8454f6dea49dddb821bfcb7569ea222bb487dfd1.
--
Ticket URL: <https://code.djangoproject.com/ticket/30591#comment:1>
* Attachment "ticket-30591.diff" added.
* owner: nobody => Adnan Umer
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/30591#comment:2>
* has_patch: 0 => 1
Comment:
[https://github.com/django/django/pull/11683 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/30591#comment:3>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/30591#comment:4>
Comment (by GitHub <noreply@…>):
In [changeset:"579909a13feb958f75d1d77e9995cef8f2b9c2a3" 579909a1]:
{{{
#!CommitTicketReference repository=""
revision="579909a13feb958f75d1d77e9995cef8f2b9c2a3"
Refs #30591 -- Fixed introspection of check and unique column constraints
on MariaDB.
Unnamed unique and check columns constraints have the same name as
a column. Ensure uniqueness by using custom names.
Thanks Adnan Umer for the report.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30591#comment:5>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/30591#comment:6>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"241deed2590bcb1d8c45271d44c86eaedfb57119" 241deed2]:
{{{
#!CommitTicketReference repository=""
revision="241deed2590bcb1d8c45271d44c86eaedfb57119"
Fixed #30591 -- Fixed recreation of foreign key constraints on MySQL when
altering type of referenced unique field.
Thanks Mariusz Felisiak for tests and Matthijs Kooijman for
investigation and initial patch.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30591#comment:7>
Comment (by Mariusz Felisiak <felisiak.mariusz@…>):
In [changeset:"acb11725f814b925d394f3923241f741b834d1b9" acb1172]:
{{{
#!CommitTicketReference repository=""
revision="acb11725f814b925d394f3923241f741b834d1b9"
[3.0.x] Fixed #30591 -- Fixed recreation of foreign key constraints on
MySQL when altering type of referenced unique field.
Thanks Mariusz Felisiak for tests and Matthijs Kooijman for
investigation and initial patch.
Backport of 241deed2590bcb1d8c45271d44c86eaedfb57119 from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30591#comment:8>
Comment (by GitHub <noreply@…>):
In [changeset:"937ddaff55efbfb4a9560603bbc8c5b17d9e1364" 937ddaff]:
{{{
#!CommitTicketReference repository=""
revision="937ddaff55efbfb4a9560603bbc8c5b17d9e1364"
Refs #30591 -- Fixed too long identifier crash in
migrations.test_operations on MySQL 8.0.16+.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30591#comment:9>
Comment (by Mariusz Felisiak <felisiak.mariusz@…>):
In [changeset:"8ce932a20a272381aff6a913954c64dce114071d" 8ce932a]:
{{{
#!CommitTicketReference repository=""
revision="8ce932a20a272381aff6a913954c64dce114071d"
[3.0.x] Refs #30591 -- Fixed too long identifier crash in
migrations.test_operations on MySQL 8.0.16+.
Backport of 937ddaff55efbfb4a9560603bbc8c5b17d9e1364 from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30591#comment:10>
Comment (by Mariusz Felisiak <felisiak.mariusz@…>):
In [changeset:"5220ca8d8a109721378e8d4c7f32e342c3a83af6" 5220ca8]:
{{{
#!CommitTicketReference repository=""
revision="5220ca8d8a109721378e8d4c7f32e342c3a83af6"
Refs #30591 -- Adjusted table rebuild for non-pk relationship on SQLite.
The existing code was only accounting for primary key changes and not
all unique key fields that can be referenced.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30591#comment:11>