Migrating from OneToOneField to ForeignKey in Django models

[Maciej Szopiński]

Hi everyone,

I've encountered an issue when working with django and I can't seem to find a way out of this..

I am using django 1.7.2 and a MySQL database. 
I have a model that was using a One-to-One relationship with two other models. At first I thought, the One-to-One relationship will be enough, but as things changed in the project I had to change the relationship to Many-to-One.

I changed only two lines in my code, in my model I had:

product = models.OneToOneField(Product)
category = models.OneToOneField(Category)

and changed it to:

product = models.ForeignKey(Product)
category = models.ForeignKey(Category)

I created the db migrations using ./manage.py makemigrations, but when I run the migration with 'migrate' it keeps throwing this error. 

django.db.utils.OperationalError: (1553, "Cannot drop index 'product_id': needed in a foreign key constraint")

I tried to check what sql operations are executed in this case and it seems that django tries to run 

ALTER TABLE 'xxx' DROP INDEX 'yyy' and
ALTER TABLE `xxx` DROP FOREIGN KEY `xxx_yyy_id_{some_hash}_fk_yyy_id`;

I am not sure if this is the right order for these operations, when running it manually on the database in the reverse order (first the DROP FOREIGN KEY then DROP INDEX) it works correctly. 

Have you encountered this issue before? Have you got any suggestions on how to resolve this situation? 
I would like to avoid any manual SQL changes outside of django migrations. 

Thanks in advance. 

Best regards, 
Maciej Szopiński

[Collin Anderson]

Hi,

Did you figure it out? This seems like a bug. Can you reproduce it with a fresh project?

Thanks,

Collin

[Łukasz Harasimowicz]

Hi Colin.

On behalf of my colleague I will answer your question:

We did not have time (at this moment) to investigate this problem any further. We've added a raw sql commands to disable foreign key checks during this migration. We could do it since we are still learning Django (and it's new migrations) and in the end we will probably remove all current migrations altogether (just before initial deployment). However we also think that this might be a bug and we will try to reproduce this problem with a fresh project. Hopefully sometime this week.

[Łukasz Harasimowicz]

It's me again.

I have managed to reproduce the problem and I have created a ticket: https://code.djangoproject.com/ticket/24163.

[Cajetan Rodrigues]

Hi,

I faced this issue recently and stumbled onto this thread.

I see that the ticket has been fixed and closed already.

How do I see which Django release has the fix shipped with?

Thanks for your help.

Cajetan.

[Simon Charette]

Hi Cajetan,

You can visit the ticket [1] and have a look and the
commit messages. In this case the fix have been
backported to 1.7.4[2] and should be part of Django 1.8+.

Simon

[1] https://code.djangoproject.com/ticket/24163
[2] https://github.com/django/django/commit/db2a97870d74bc689428d9c2a942115ef799f2d2