It would be a Very Good Thing to support obtaining data without using Views - for example, to get data from database engines not supported by Drupal, or using exotic queries that can't be constructed in Views. Or, to begin work on a D7 version of Migrate before there's a stable D7 version of Views (frankly, our immediate concern)...
The fundamental approach we're planning is to allow alternate data sources to be defined via hooks. The central issue is migrate_content_process_import(), which currently:
- Fetches the SQL query from the content set's view,
- Adds joins to the map and message tables,
- If an idlist is passed, add the appropriate WHERE clauses,
- If an itemlimit is passed, apply the specified LIMIT,
- And finally, executes and iterates over the query.
The most basic approach would be, for content sets not attached to a view, to call a hook to fetch a basic SQL query and proceed from there. A more flexible approach, which wouldn't take a SQL source for granted, would be to call execution and iteration hooks. Or, Moshe's suggestion and the current front-runner, would be a callback-based approach (like menu page callbacks).
Now, with a hook approach, there needs to be a method to tie the hook names to particular content sets. I.e., to call hook_migrate_execute_FOO(), what is the FOO that uniquely identifies this content set? Well, we would need a unique, function-name-valid identifier for each content set (as suggested by frankcarey). So, #698178: Unique alphanumeric IDs for content sets would be a prerequisite for that approach.
Comments
Comment #1
BenK commentedSubscribing...
Comment #2
mikeryanA note that Migrate 2.0 for D7 supports migrations based on SQL queries (indeed, at the moment that's all it supports...).
Comment #3
mikeryanMigrate 2.0 supports flexible data sources.