Plata migrations and foreign key constraints on product relations

[arteme]

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 simple.Product as the product class. This creates a foreign-key constraint in product.stock.StockTransaction and shop.OrderItem model tables to simple.Product model table, like:

ALTER TABLE `stock_stocktransaction` ADD CONSTRAINT `product_id_refs_id_549808cd371cc71a` FOREIGN KEY (`product_id`) REFERENCES `simple_product` (`id`);

and

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:

IntegrityError: (1452, 'Cannot add or update a child row: a foreign key constraint fails (`test_billing`.`shop_orderitem`, CONSTRAINT `product_id_refs_id_66f6c467790e3655` FOREIGN KEY (`product_id`) REFERENCES `simple_product` (`id`))')

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 simple.Product, but rather settings.PLATA_SHOP_PRODUCT so that the correct constraints are generated on the initial migration right away. This might still be problematic -- what should happen if the user changes their PLATA_SHOP_PRODUCT setting mid-project?

[matthiask]

Related to #26.