Closed (fixed)
Project:
Migrate
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
1 Dec 2011 at 16:24 UTC
Updated:
14 May 2012 at 17:10 UTC
The migrate_example BeerUser migration sets up deduping of usernames. Running
drush mi beerterm
drush mi beeruser
Gives usernames alice, alice_2, bob, and charlie. Then running
drush mi --update beeruser
changes the username to alice, alice_3, bob_2, charlie_2. So, we need to be sure not to rewrite usernames when updating existing content.
Comments
Comment #1
mikeryanThis is harder than it looks. If we simply skip the dedupe logic when updating existing content, we get "Integrity constraint violation: 1062 Duplicate entry 'alice' for key 'name'" on the 2nd alice account - we've passed through the original "alice", which conflicts with the first "alice". We want to keep "alice_2" on that account - but the logic is applied before we have the destination side in hand - all we know is we have a source username of "alice" and don't know which is the right deduped username corresponding to the current source row.
It seems like we may need to procrastinate handling of dedupe() to the prepare() stage...
Comment #2
donquixote commentedYes, that sounds absolutely reasonable.
Is this difficult to pull off?
EDIT:
I might help out, if in return you accept my patches in other issues :)
Comment #3
mikeryanFinally, fixed on D6 and D7! I was able to do it in the current handleDedupe() function. It should be noted that, because we don't know at update time what the original intended value was, using dedupe() means that the field being deduped will not be updated from the source value. I.e., if you migrate a user whose source username was frank, and they get deduped to frank_1, if they get changed to bill on the source side an update will still maintain frank_1.