An important task, that I just noticed lacks a proper issue in the queue. This will include a basic tutorial (a simple migration that requires no programming), and detailed API documentation along with an advanced tutorial exercising the API.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | migrate.api_.php_.txt | 3.48 KB | webchick |
Comments
Comment #1
matason commentedI'm in the process of migrating some data from a custom built PHP/MySQL web site into Drupal and Migrate and TW modules have been a huge help... so thanks!
I came across this documentation - http://drupal.org/node/415260 whilst searching for information about migrate's hooks, it's marked incomplete but is also out of date. I added a short note there about the removal of "destination" and last night I started studying the code and drafting some new docs, didn't spot this issue until just now, is it something you have in hand or is it worth me continuing? I was thinking also of contacting frankcarey to see if he's interested in working on some new docs?
Comment #2
moshe weitzman commentedThanks for volunteering. I suggest you we abandon that book page and instead expand upon the help that ships with migrate module. Install the advanced help module to see it. Paches welcome.
Comment #3
mikeryanTomorrow I've got a day to focus on migrate, and I'm planning on really fleshing out the API docs - please don't invest too much time in API docs until I commit that, then feel free to contribute improvements.
I agree with Moshe - the advanced_help with the module should serve as the reference documentation. The d.o pages should serve as a cookbook, and an excellent place for migrate users to contribute concrete examples of different use cases.
Thanks.
Comment #4
matason commentedSounds good, maybe we can nudge Frank to update those d.o. pages :)
Comment #5
joachim commentedHaving just installed migrate and taken a look, I would suggest docs need to begin by outlining how migrate works.
Coming from modules like node_import, I was expecting to upload a CSV file, not see a list of views to pick. This different approach takes a bit of getting used to! (but I can see the advantages and flexbility it gives!)
So something that says:
- you migrate fields defined in a view
- the import process from a file is therefore:
1. upload csv with TW to create your own table within the Drupal DB
2. use TW to expose the columns in this table to Views
3. create a view that has the fields you want
4. import from this view.
Comment #6
matason commentedJust to add to that last comment:
The import process from a MySQL database:
1. edit settings.php, look for $db_url which is normally a string containing your database connection URL. Change this variable to an array adding the a connection URL for the database you want to import:
Original
Amended
2. go to Table Wizard - admin/content/tw - in the "Add existing tables:" section you should be able to add "Available tables in import connection: " - select the tables to add and click "Add tables"
3. go to Migrate - admin/content/migrate/content_sets - fill in the "Add a content set", a list of Views that have been created by the previous step will be available enabling you to select an "import_db" and match source fields to destinations.
4. go to Migrate - admin/content/migrate/process - tick the "Import" checkbox, fill in other options if you want to and hit "Submit"
Comment #7
joachim commentedBut if your import table is in another DB then you can't do joins on your current data, can you?
There's something else I'm confused about.
Presumably one very cool application of migrate is adding further data to existing stuff.
But when I tried this with users I got stuck. My data to import had email addresses, which I assumed was enough to join onto the Drupal users table. However, only the uid is a listed key on the tw relationships page. I'm wondering if there's part of the procedure I've not understood!
Comment #8
mikeryanI've committed a bunch of work I've done on the documentation over the last couple of weeks, still some holes and cleaning up to do, but feedback on what is there is welcome.
@joachim: Yes, you can join tables in different databases on the same server (at least in MySQL). E.g., SELECT * FROM {users} u INNER JOIN external_db.my_table t ON u.mail=t.email_address. You can't make Views do that through its UI, however - the migrate module does some programmatic manipulation to achieve the joins it needs.
Now, what you're trying to do is update existing users rather than create new users, correct? That is not something you'll be able to do without implementing code (i.e., hook_migrate_prepare_user()). Please review the newly-updated documentation and see if that helps you understand how it all works.
Comment #9
matason commentedExcellent work mikeryan, I'm trying to find time to have a proper look but in the meantime thanks for all your hard work :)
Comment #10
frankcarey commentedfrank has been nudged :) I'm finishing up this project finally, and It looks like our custom modules are going to need some significant re-writes to get back up to speed with the progress of this module. I have our guy travis starting work on this now, so I'll point him to the new docs and have him post patches if he has something to add. I'll probably be working close by him as well and will do the same.
Comment #11
webchickNot strictly related to the topic at hand, but I had to sit down and learn Migrate's hooks tonight, and I always learn stuff better when I document it.
Here's a migrate.api.php file, for consistency with how Drupal 7 handles API documentation. I was able to copy/paste quite a bit from the advanced help stuff, though just accidentally stumbled across it, since I would *never* have looked for hook documentation in advanced help.
Hope someone finds it useful! :)
Comment #12
joachim commentedOh wow, thanks webchick!
+1 for including this!
Comment #13
mikeryan@webchick - Committed migrate.api.php, thanks!
Comment #14
mikeryanNo further work going into Migrate 1, there's a separate issue out there for Migrate 2.