First off, I have searched for a solution here, and on Github, this has never been answered specifically from what I can see, none of the answered items work.
Migrated Magento 1 address information does not work in Magento 2. I also see that people have this issue when running older Magento 2 versions as well.
Reference question: Magento 2 versions have this issue, resolve by 'upgrading' The solutions claim to upgrade Magento 2 ~2.2, but I already run Magento 2.3.5 which means I should have the 'fixes applied' already.
I already have Magento 2.3.5 so this is related to migrated data rather than an older version issue
Reference question: Magento 2 Customer address not showing properly The solution here is viable: by creating a new module (overriding
AddressMetadataInterface) and changing a constant ATTRIBUTE_SET_ID_ADDRESS.
However, I personally feel that fixes for Magento 1 migrated data to 'work' to Magento 2 should not relate to overriding any Magento 2 files - overriding are for when Magento 2 works perfectly as it should. I have to create a MyVendor_Magento1FixesModule which feels strange.
While this might be a solution, its a 'hacky solution' that could get lost on new migrations. Changing a *CONSTANT by changing a constant value doesn't feel right either.
Besides, I even found code that does this : 'entity_type_id' => 2' **instead of ** 'entity_type_id' => AddressMetadataInterface::ATTRIBUTE_SET_ID_ADDRESS, so I really do not understand why constants aren't used everywhere.
(Imagine starting a new migration for another project with the default core Magento 2 installation files, without this module). If possible, I want users to advise on database related fixes rather.
I would rather want to fix these Magento 1 migrated database issues directly inside the Magento 2 database, even if it might be more complicated.
The closest solution is discussed on Github Magento issue 5873, but discusses it from the point of view of deleting migrated attribute sets - which are already tied to data I use ('customer_address' entity_type_code for attribute sets used for another module), so I would like to prevent issues with that module.
Too much information?
I want users to see I have done my own research and see reason why this is not a duplicate, because there are various reasons described above why I need an alternative.
Question
I am currently investigating the issue by trying to figure out in the database.
For further investigation, I just need some advice either by a direct answer, or alternatively just information on which tables the customer_address entity_type_code data depends on.
Currently, I have customer_entity, customer_address_entity, eav_entity_attribute, eav_attribute_group, eav_attribute_set which relate to the customer_address entity.
Are there any others tables? (I am already busy trying to join table data to see what I get).
Thanks so much!
