New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plata migrations and foreign key constraints on product relations #33

Closed
arteme opened this Issue Sep 21, 2012 · 1 comment

Comments

Projects
None yet
2 participants
@arteme
Copy link

arteme commented Sep 21, 2012

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

This comment has been minimized.

Copy link
Owner

matthiask commented Nov 26, 2012

Related to #26.

@matthiask matthiask closed this in 5fdb9d5 Nov 27, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment