data-migration-tool
data-migration-tool copied to clipboard
Data Migration: core_store table not having prefix applied as part of join
Preconditions
- Magento 1 version-1.9.4.5 Tables prefixed "mage_". Multiple stores configured
- Magento 2 version-2.3.5p2. Tables prefixed "m2_".
Steps to reproduce
- Install data migration tool-2.3.5
- Add <source_prefix>mage_</source_prefix> and <dest_prefix>m2_</dest_prefix> to config.xml
- Migrate settings successfully
- Migrate Data
Expected result
- Data migration should complete
Actual result
- Data migration fails
[2020-08-20 16:39:55][INFO][mode: data][stage: integrity check][step: Data Integrity Step]: started 90% [=========================>--] Remaining Time: < 1 sec In Mysql.php line 110:
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'magento_1945.core_store' doesn't exist, query was: SELECT DISTINCT child
.store_id
FROM mage_xmlconnect_application
AS child
LEFT JOIN core_store
AS parent
ON child.store_id = parent.store_id WHERE (child.store_id IS NOT NULL) AND (parent.store_id IS NULL)
In Mysql.php line 91:
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'magento_1945.core_store' doesn't exist
Additional notes
Error appears to be thrown from Migration\Step\DataIntegrity\Model\OrphanRecordsChecker->getOrphanRecordsIds()
Note that in the SQL JOIN statement the 'child' xmlconnect_application table name is prefixed correctly, but the 'parent' part of the JOIN references core_store table and does not contain the DB table prefix. Thus this is not an error caused by an incorrect or missing <source_prefix> node.
It appears that the parentTable property of the OrphanRecordsChecker class is being injected into the constructor with the table prefix not set.
Hi @sweetappleuk. Thank you for your report. To help us process this issue please make sure that you provided sufficient information.
Please, add a comment to assign the issue: @magento I am working on this
- Join Magento Community Engineering Slack and ask your questions in #github channel.
To further confirm, modifying the source database to remove the 'mage_' table prefix allows the data import to proceed successfully with no other modifications.
The testing matrix for this tool definitely needs to be expanded to account for M1 sites with table prefixes, or updated instructions for those migrating from M1 to explicitly state that table prefixes should be removed from the source M1 database.