We currently create a customer profile for each order. That means lots of duplicates for no reason. It would be far better to consolidate these.
This also might not be a migrate issue - there may be a better way to do it.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | consolidate_duplicate_profiles-1212174-10.patch | 1.56 KB | deciphered |
| #7 | commerce-duplicate-profiles-1.patch | 1.58 KB | kscheirer |
Comments
Comment #1
drewish commenteddoes it cause any problems if they're different bundle types? shipping vs billing?
Comment #2
bojanz commentedYes, we can't reference a profile of a different bundle, Commerce will complain, and there's no guarantee that profiles of different bundles have the same field...
We can only consolidate identical profiles of the same bundle.
Comment #3
rfay@drewish such a pleasure to have you here working with Commerce Migrate!
Comment #4
drewish commented@rfay, thanks! picked up a side project and you have no idea how excited i was to find this module an not need to start from scratch.
Comment #5
rfayComment #6
kscheirerProblem
When importing profiles using customer_billing_profile.inc there is no check for duplicate profiles. Both Addressfield and Commerce Profile do have such checks, but they run only during form submits, and are focused on what happens when a user edits a profile or creates a new one. Instead, we are creating new entities directly when migrating.
Reason
The profiles are created from individual uc_orders. Ubercart stores address/billing info directly on the order itself. If a user has ordered more than once, it is quite easy for more than 1 order to have the same address information. We still need to process all the orders to keep the migrate map intact and allow commerce to properly associate the new profile with all the user's orders.
Proposed Solution
In order to prevent a duplicate profile from being created, instead mark the new profile as a revision of the existing profile. This seems to keep the migrate map intact for the later sourceMigration() call in order.inc. The attached patch uses an entity field query to check for the existence of a commerce profile with the same data as the current profile being created.
Comment #7
kscheirerAnd the actual patch.
Comment #8
Anonymous (not verified) commentedThank you! Committed to dev branch today at DrupalCon!
Comment #10
decipheredThis queries the source UID, not the destination UID, which therefore means that for anyone using a Users migration this will not actually do anything.
New patch resolves the issue.
Comment #11
kscheirerGood catch, my migration preserved uids so this wasn't an issue for me. Thanks!
Comment #12
kscheirerComment #13
dwkitchen commented