magento2: Database Schema: Incorrect Unique Indexes
Regarding my database inspections for migrating Mage1->2 I’ve found this thing:
The unique key which conflicts is in table cataloginventory_stock_item with the name
UNQ_CATALOGINVENTORY_STOCK_ITEM_PRODUCT_ID_WEBSITE_ID for (product_id,website_id).
IMHO: This does not make sense because of the column stock_id. The unique key must be on (product_id,stock_id). This newly introduced column website_id is totally wrong. In table cataloginventory_stock you also have added the column website_id which doesn’t make sense.
You can still have the same stock_id associated to multiple website_ids or vice versa; so a third table would be necessary for assigning stock_ids to website_ids.
The current solution in table cataloginventory_stock looks like that for each website you must create its own stock_id … 👎
If I’m absolutely wrong with my IMHO a short explanation would be great on what kind of “multiwarehouse” feature you are working on!
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Reactions: 1
- Comments: 17 (13 by maintainers)
Links to this issue
Commits related to this issue
- MAGETWO-33564: [GitHub] Database Schema: Incorrect Unique Indexes #1002 — committed to magento/magento2 by RuslanKostiv1 8 years ago
- MAGETWO-33564: [GitHub] Database Schema: Incorrect Unique Indexes #1002 — committed to magento/magento2 by RuslanKostiv1 8 years ago
- MAGETWO-33564: [GitHub] Database Schema: Incorrect Unique Indexes #1002 — committed to magento/magento2 by le0n4eg 8 years ago
- Merge pull request #678 from magento-nord/NORD-PR Bugs fixed: * MAGETWO-33564: [GitHub] Database Schema: Incorrect Unique Indexes #1002 * MAGETWO-56095: When category has products that are not visi... — committed to magento/magento2 by magicbunneh 8 years ago
- Merge pull request #1002 from magento-falcons/MAGETWO-67099 - MAGETWO-66322 Dump env-specific and sensitive variables to env config file - MAGETWO-64317 POST request to /setup/index.php/session/prol... — committed to magento/magento2 by viktym 7 years ago
- ENGCOM-6064: Remove try-catch construction #1002 - Merge Pull Request magento/graphql-ce#1002 from TomashKhamlai/graphql-ce:coverage-downloadable-links-data-provider - Merged commits: 1. 7dc9e64... — committed to magento/magento2 by magento-engcom-team 5 years ago
- ENGCOM-6064: Remove try-catch construction #1002 — committed to magento/magento2 by lenaorobei 5 years ago
Hi,
Regarding unique key on (product_id,website_id) in cataloginventory_stock_item table it’s legacy, and in the scope of Multi Location Inventory track has already been fixed, but it’s still not in mainline. Correct index is (product_id,stock_id) as you mentioned in your post. Having (product_id,website_id) index you will stuck with conflicts implementing Multi Location Inventory (MLI).
Knowledge about Website_Id are already eliminated from CatalogInventory data interfaces both from https://github.com/magento/magento2/blob/develop/app/code/Magento/CatalogInventory/Api/Data/StockInterface.php and https://github.com/magento/magento2/blob/develop/app/code/Magento/CatalogInventory/Api/Data/StockItemInterface.php
It’s true, so in the scope of MLI we will deliver Link interface which describe the relationship between Source (MLI interface which describes physical Stock extending basic Stock interface from CatalogInventory module) and Website.
There is also Repository interface to manage this entity.
All the links belonging to Source (Stock) would be available through the Source DTO
Hi @SchumacherFM. Thank you for your report. The issue has been fixed in magento/magento2#27399 by @serhiyzhovnir in 2.4-develop branch Related commit(s):
The fix will be available with the upcoming 2.4.0 release.
Hi @korostii We are not able to backport all fixed issues in 2.2.0 release to 2.1 and 2.0 releases. We will backport the most critical issues based on PO decision or the most up voted issues from public GitHub. Also, if we will get a pull request from Magento Community with the backport, we will accept it and deliver with upcoming patch releases.
@SchumacherFM fixed in develop, not yet backported to 2.0 and 2.1.
Still tracking internally as MAGETWO-33564 for mainline fix