I have a need to migrate about 10 tables that are provided by our custom drupal modules.
All of those tables are defined through the Schema API.
Since it's a bit stupid to write a handler for each one of those, changing only the fields, I thought I'd write a generic plugin that takes the table name and figures out the rest. Feels like something that should be in the base Migrate module.
Supports updates. Completely untested.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | table.inc_.txt | 5.52 KB | bojanz |
| #3 | table.inc_.txt | 5.52 KB | bojanz |
| #2 | table.inc_.txt | 4 KB | bojanz |
| table.inc_.txt | 3.76 KB | bojanz |
Comments
Comment #1
bojanz commentedAlso supports compound primary keys, which complicates things a bit, as you can see.
Also, wrong issue status.
Comment #2
bojanz commentedBetter.
Comment #3
bojanz commentedThis one should be near-final.
Comment #4
bojanz commentedThis is the version we ended up using.
It's only slightly different than #3.
Comment #5
drewish commentedDid you have any problems with rollbacks? Working on inserting records into {users_rolls} It seemed to be trying to to delete WHERE (destid1 = 1) AND (destid2 = 2) rather than (uid = 1) and (rid = 2). I'm not sure if it's this class or the rollback code that's passing the wrong keys names in.
Comment #6
bojanz commentedNot that I remember. It's really been a while though.
Comment #7
drewish commentedIt either didn't work or they changed the keys they pass in since you wrote this. We got a fix for it over at #1147366: Migration::rollback() should use the MigrationDestination's field names for keys..
Comment #8
mikeryanFinally! I've reviewed and committed this enhancement (with a few tweaks, plus an example and test). I can see, now that I've finally looked, that it should be very handy, thanks!