magento2
magento2 copied to clipboard
Inventory update of Configurable Product fails when database uses prefixes
Preconditions and environment
- Magento version: 2.4.6-p1
- Database encoding: utf8mb3_general_ci
- Setup Magento to use Database prefix.
- Example of Prefix: tst_
- Establish prefix in app/etc/env.php
- Rename all Tables of the Database with the prefix defined.
- Flush Cache and Redeploy Magento.
Steps to reproduce
After you setup Magento with Database prefix, create a configurable product A0 with 2 Simple Products inside A1 and A2. Then assign inventory source to the two simple products. Then try to set the inventory quantity for the Simple Products A1 and A2.
Expected result
The set quantity is saved and the quantity is recorded in the inventory Table.
Actual result
Error message appears (example) when trying to save:
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'gtfnvnbmcy.cataloginventory_stock_status' doesn't exist, query was: UPDATE
cataloginventory_stock_statusSET
stock_status= ? WHERE (product_id = 745)
And the quantity is not saved.
Under this example of error, the product ID 745 is set for the Configurable product A0 and not for the Simple Products A1 and A2.
Additional information
I tried to modify the Inventory quantity in the Simple Products A1 and A2 who is part of Configurable Product A0 and also inside Configurable Product A0 directly. It gives the same error. It means that the Simple Product who is belonging to a Configurable Product uses the same saving protocol or script.
It seems that the SAVING action does not allow to assign the expected prefix to the database updating query. In the above example, it should point to table gtfnvnbmcy.tst_cataloginventory_stock_status instead of gtfnvnbmcy.cataloginventory_stock_status
Other information: It seems that the processor of the saving is located in this path: /public_html/vendor/magento/module-inventory-indexer/Model/ResourceModel/UpdateLegacyStockStatus.php This .php code calls the Table name cataloginventory_stock_status which is OK. But prefix is not added.
Release note
I can provide screen captures and testing results on demand. We Tested on Production server, Test Server and also on a fresh-new Magento installation: Same outcomes.
Triage and priority
- [X] Severity: S0 - Affects critical data or functionality and leaves users without workaround.
- [ ] Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
- [ ] Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
- [ ] Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
- [ ] Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.
Hi @vbidou. Thank you for your report. To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:
-
@magento give me 2.4-develop instance
- upcoming 2.4.x release - For more details, review the Magento Contributor Assistant documentation.
- Add a comment to assign the issue:
@magento I am working on this
- To learn more about issue processing workflow, refer to the Code Contributions.
Join Magento Community Engineering Slack and ask your questions in #github channel. :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting. :clock10: You can find the schedule on the Magento Community Calendar page. :telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.
Hi @engcom-Dash. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:
-
- Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
-
- Verify that issue has a meaningful description and provides enough information to reproduce the issue.
-
- Add
Area: XXXXX
label to the ticket, indicating the functional areas it may be related to.
- Add
-
- Verify that the issue is reproducible on
2.4-develop
branchDetails
- Add the comment@magento give me 2.4-develop instance
to deploy test instance on Magento infrastructure.
- If the issue is reproducible on2.4-develop
branch, please, add the labelReproduced on 2.4.x
.
- If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
- Verify that the issue is reproducible on
- Join Magento Community Engineering Slack and ask your questions in #github channel.
Dear Team, My developer was able to define a temporar fix that we deployed successfully, but it is only a patch which is outside the folder vendor/magento. If you identify and fix the issue in future Magento release, we will remove this temporar fix from the installation before the upgrade sequence. Best regards
Hello Team, Is there any progress on this one ?
I have just bumped into this one. @engcom-Dash @vbidou
There's been a surprise number of these across modules since autumn 2021 - and in the end the problem is always the same:
There are multiple versions of getTableName() across the Magento classes and NOT ALL OF THEM add the prefix properly
For example I have encountered that
$this->resourceConnection->getTableName()
adds prefix
but
$this->resourceConnection->getConnection()->getTableName()
does NOT add prefix
So in the file /public_html/vendor/magento/module-inventory-indexer/Model/ResourceModel/UpdateLegacyStockStatus.php
/**
* Update legacy stock status for given skus.
*
* @param array $dataForUpdate
*/
public function execute(array $dataForUpdate): void
{
$connection = $this->resource->getConnection();
$tableName = $connection->getTableName('cataloginventory_stock_status');
should probably be
$connection = $this->resource->getConnection();
$tableName = $this->resource->getTableName('cataloginventory_stock_status');
and then the error goes away
(Now it should be consistent and $this->resourceConnection->getConnection()->getTableName()
should add prefix surely?)
Brilliant demonstration iphigenie ! @engcom-Dash, do you think it can be fixed in the core of magento ? You haven't responded to this one yet. Please update us.
Hi @vbidou
Thanks for reporting and collaboration.
Verified the issue in magento developer instance and the issue is not reproducible.
The quantity is being saved and getting updated in the inventory table.
Please refer the attached screenshots.
Indeed it seems to work on your side. Which Magento version have you used ? Have you added a prefix to the database ? Have you used customized storage locations (not default one) ? (In my case I used customized MSI storage source) Have you tried to update and save those quantities both in Simple and Grouped products ? No error ? Thank you for the support.
@engcom-Dash I can see the test has prefix but did it have sources set up or is it on default inventory?
Adding some context - I was testing configurable on my site as tired of bumping into issues with Grouped products. And creating a configurable product with 1 child and I bumped into that error.
I can't remember if I told it to skip configuring inventory at product creation or if I went through assigning sources and stock levels - but on save it had created the product but failed on the stock information
Live site of long existence. Version open source ver. 2.4.6-p3. MSI with 2 sources on 1 site.
I made the code change mentioned above and it no longer has that error on creation.
I have the same reading. We should use MSI and not default inventory source. In my case I created the MSI post-factum the product creation. @engcom-Dash please feedback on this. Thank you.
Hi @vbidou
Thanks for reporting and collaboration.
Verified the issue on magento 2.4-developer instance and the issue is reproducable.
When the database uses prefixed the inventory update of configurable products is failing. We are seeing the below error when trying to save:
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'gtfnvnbmcy.cataloginventory_stock_status' doesn't exist, query was: UPDATE cataloginventory_stock_statusSETstock_status= ? WHERE (product_id = 745)
Please refer the screenshot attached.
:white_check_mark: Jira issue https://jira.corp.adobe.com/browse/AC-10750 is successfully created for this GitHub issue.
:white_check_mark: Confirmed by @engcom-Dash. Thank you for verifying the issue.
Issue Available: @engcom-Dash, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.
:x: You don't have permission to export this issue.
Just a quick nudge that the issue BEHIND this is an inconsistency between variants of getTableName
in the context here
$this->resourceConnection->getTableName() adds prefix but $this->resourceConnection->getConnection()->getTableName() does NOT add prefix
This needs to be documented very clearly OR perhaps made more consistent
We have the same problem fixed it tmp with a patch. Patch: UpdateLegacyStockStatus_2.4.6.txt
Hi,
Internal team has started to work on it
Thanks.
Hi @vbidou
Verified the issue on the latest Magento 2.4 dev instance but the issue is no longer reproducible.
Steps to reproduce :
- After you setup Magento with Database prefix, create a configurable product A0 with 2 Simple Products inside A1 and A2.
- Then assign inventory source to the two simple products.
- Then try to set the inventory quantity for the Simple Products A1 and A2.
Please verify the attached screenshot:
Thanks. Which M2 version have you used ? Which DB prefix have you set ?
Hi @vbidou
We have tested in Magento 2.4 dev instance.
DB prefix : tst_
Please verify the attached screenshot
Thanks for the follow-up. Interesting. I tested on Magento version: 2.4.6-p1. Is it possible that you Dev version received a fix meanwhile ? Which version this Dev instance plays on ?
Hi @vbidou,
We tested the issue on Magento versions 2.4-dev, 2.4.6-p6-dev, and 2.4.6-p1-dev, and this issue is already fixed in all dev versions, and the issue is not reproducible anymore. I've included the screenshot below for your reference.
Hi @vbidou
As there is no activity on this issue for a long time, we believe the issue has been resolved, hence closing this issue. Feel free to raise a new issue or reopen this if you still face it.
Thank you.