Hello!
I’m trying to execute database migration from Hawthorn.2 release to Ironwood.master release and I’m facing the following error:
File “/edx/app/edxapp/venvs/edxapp/local/lib/python2.7/site-packages/MySQLdb/connections.py”, line 36, in defaulterrorhandler raise errorclass, errorvalue django.db.utils.IntegrityError: (1215, ‘Cannot add foreign key constraint’)
What could be the solution of the problem?
Thank you in advanced for your time
Hello
I have experienced this kind of error because of some data integrity issue. To fix it you have to exactly find which relation cannot be created. Then if there is a record with a value in FK column which is not presented in referenced PK column. Fix any issue you find and then retry to migrate.
In addition although it might not help for your problem, it would be better choice to migrate from a master release to another. so you may want to first upgrade to hawthorn.master and then upgrade to ironwood.master .
Dear Mahyard,
Thank you very much for your answer and help. I’m trying to fix the error following your guideline.
Regarding the releases, I tried the migration from hawthorn.2 to ironwood.master. I will try also hawthorn.master to ironwood.master.
Thank you again.
Ioannis
@pappasj, are you running the vanilla Open edX codebase on your instance? If yes, upgrading from hawthorn.master to ironwood.master should work. If there are any customizations involving database migrations, you will have to resolve them manually.
File “/edx/app/edxapp/venvs/edxapp/local/lib/python2.7/site-packages/MySQLdb/connections.py”, line 36, in defaulterrorhandler raise errorclass, errorvalue django.db.utils.IntegrityError: (1215, ‘Cannot add foreign key constraint’)
Can you post the full traceback so that there is more information about which model/table and field are triggering this issue?
Ok, so I was able to resolve this issue. I hope pointers below will give idea about the direction to look for.
In my case, failed migration was trying to create a new table with some foreign columns.
I started by checking duplicates in all the foreign tables referenced in current table (being created/altered through this migration file). No discrepancies there.
Next, I checked all the tables in information_schema.schemata and found that the new table which was being created had a different collation than the one being referenced as foreign.
Next, I checked the default collation set on the database and corrected it to match as per expectation. (WARN: Be careful here though to fully understand what those collations mean for your data first before taking this action)
After that, dropped the already created table due to failed migration, reapplied migrations and it worked like a charm.