Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Plata migrations and foreign key constraints on product relations #33
This is an issue that I ran into when switching from a SQLite back-end to a MySQL back-end with InnoDB engine. While this is a danger zone from both Django and South view points, it highlights an issue in Plata migrations that others might face as well.
The problem is this: the migrations were created with
ALTER TABLE `stock_stocktransaction` ADD CONSTRAINT `product_id_refs_id_549808cd371cc71a` FOREIGN KEY (`product_id`) REFERENCES `simple_product` (`id`);
ALTER TABLE `shop_orderitem` ADD CONSTRAINT `product_id_refs_id_66f6c467790e3655` FOREIGN KEY (`product_id`) REFERENCES `simple_product` (`id`);"
Now, when a Plata user creates their own project, they will create their own product model, but creating either stock transaction record or order item record results in an integrity check error like:
The simplest work-around for this is for the developer to add new migrations for these models so that new foreign key constraints are generated:
./manage.py schemamigration plata.product.stock --auto ./manage.py schemamigration plata.shop --auto ./manage.py migrate
However, this may be problematic for users, who have Plata installed system-wide as South will, of course, attempt to create these migrations in site-packages Plata directories which a regular user doesn't have access to. Furthermore, distributing these migrations and applying them at deployment may be problematic.
A possible solution on Plata side may be to modify the migration scripts to not use