Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Any plans to add support to Redhen for the migrate module? Or any other plans for easing the migration process?
Thanks,
Mickey
Comment | File | Size | Author |
---|---|---|---|
#12 | redhen-migrate-1781538-12.patch | 14.12 KB | John Carbone |
#7 | redhen-contact_migrate-1781538.patch | 7 KB | arknoll |
#7 | redhen-dev-contact_migrate-1781538.patch | 7.12 KB | arknoll |
Comments
Comment #1
seanberto CreditAttribution: seanberto commentedWe've written some migration classes for one of our clients. It will take a bit more abstraction before we are ready to release this work. Happy to accept patches for this as well. It's definitely a high priority item on our roadmap.
Comment #2
micnap CreditAttribution: micnap commentedThanks for the response. I'm currently in the middle of the migration using the Migrate module. Everything has gone smoothly except the redhen_email field. I can get the email imported but am not able to set any of the subfields (hold, bulk, default). I've tried using subfields and the prepare() method. Can you share how you were able to import to the subfields of the redhen_email field?
Thanks!
Mickey
Comment #3
micnap CreditAttribution: micnap commentedAnd of course, I get it right after posting. Adding these to my prepare function did the trick:
$entity->redhen_contact_email['und'][0]['value'] = $row->EMAIL;
$entity->redhen_contact_email['und'][0]['options']['label_id'] = 0;
$entity->redhen_contact_email['und'][0]['options']['hold'] = 0;
$entity->redhen_contact_email['und'][0]['options']['bulk'] = 0;
$entity->redhen_contact_email['und'][0]['options']['default'] = 1;
Mickey
Comment #4
seanberto CreditAttribution: seanberto commentedThat's great, Mickey. If you had the time, I'm sure that folks would love a documentation page describing your work with Migrate and RedHen.
Comment #5
levelos CreditAttribution: levelos commentedComment #7
arknoll CreditAttribution: arknoll commentedAttached is my implementation of migrate with redhen_contact sub module. I am attaching a patch for the 7.x-1.0 branch and the 7.x-1.x-dev branch.
-Alex
Comment #8
philipz CreditAttribution: philipz commentedI've just finished Redhen Contact migration using only
MigrateDestinationEntityAPI
to get key schema in MigrateSQLMap:MigrateDestinationEntityAPI::getKeySchema('redhen_contact')
and to set destination:
$this->destination = new MigrateDestinationEntityAPI('redhen_contact', 'my_contact_type');
All my fields migrated just fine including Addressfield and other attached fields/properties (first_name/last_name).
@arknoll: Is
MigrateDestinationRedhenContact
class really needed?@micnap: Thanks for the code - this was needed! :)
This should be made into
MigrateFieldHandler
at some point I think.Comment #9
kevinquillen CreditAttribution: kevinquillen commentedI just did this today, but for Organizations. Can't do a patch right now but.. :
Comment #10
kevinquillen CreditAttribution: kevinquillen commentedIs there any update on this? I too backed down to using MigrateDestinationEntityAPI::getKeySchema('redhen_org') - but I get a fatal error when the batch process begins. However no error is logged at all in log files or the database, and entities are created. Seems to be something with redhen_org entities.
Comment #11
micnap CreditAttribution: micnap commentedI'm having the same problem. I've tracked it down. The migrate module is expecting an integer as the unique id. Redhen orgs are using the name field as the unique id which is text. When the migrate module attempts to stuff the name field in its destid1 and destid2 integer fields, the migrate module chokes and spits out the generic "New object was not saved, no error provided" error. So the new Redhen org entities do get saved but the mapping from the source to the destination doesn't complete, hence the rollback doesn't work.
I've created a separate bug report for this at https://drupal.org/node/2035271
Comment #12
John Carbone CreditAttribution: John Carbone commentedHere's another go at a patch (new module) that should serve as a starting point for supporting the migrate module in Redhen. So far it works for importing Organizations and Contacts. It does support updating records for either but does not yet support revisions. A handler for email is also included.
So far I've used this code to migrate about 700K users and a large amount of organizations, both of various types, but this is the first run at a patch. It really needs a good testing method though, with test data and test migration classes. It's not perfect but I think it's ready to get some more eyeballs on it to review and fine tune it.
I'm also going to be looking at migrating memberships soon and will check back in on that one.
Here's the gist of how to use this in a migration.
For contacts:
Comment #13
John Carbone CreditAttribution: John Carbone commentedNuts. Just noticed line 10 in redhen_migrate.info needs to be removed.
+dependencies[] = redhen_migrate
Comment #14
cmah CreditAttribution: cmah commentedAny pointers on handling the Connections between Contacts and Organizations?
$this->destination = new MigrateDestinationRelation('redhen_affiliation');
seems like a good start, but constructing the endpoints array in prepare() seems pretty dicey.Comment #15
chrisrockwell CreditAttribution: chrisrockwell commented#12 worked for me during a migration of d6 content profiles to redhen contacts (4 different types). It was used in combination with DrupalNode6Migration.
I did have an issue in that, it seems, the mapping table migrate_map_machinename never had the destid2 column so I had to manually create for each one. I would love to troubleshoot more thoroughly when I have time but a cursory glance indicates those tables are built based on the destination scheme (MigrateDestinationRedHenContact::getKeySchema in this case).
Thanks for the patch @John Carbone!
Comment #16
levelos CreditAttribution: levelos at ThinkShout commentedComment #17
levelos CreditAttribution: levelos at ThinkShout commentedComment #18
tauno CreditAttribution: tauno at ThinkShout commentedMakes sense that the email field handler is needed since that's a custom field. Some of the old comments here are from during the phase when RedHen Orgs had machine names. Since orgs behave like contacts (and most other non-config entities) I would think Entity API would work well on it's own without the need for extra migration classes specifically for redhen contacts and orgs. Has anyone had the opportunity to try a migration recently just using the Entity API migration classes?