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:

  1. Fetches the SQL query from the content set's view,
  2. Adds joins to the map and message tables,
  3. If an idlist is passed, add the appropriate WHERE clauses,
  4. If an itemlimit is passed, apply the specified LIMIT,
  5. 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

BenK’s picture

Subscribing...

mikeryan’s picture

A note that Migrate 2.0 for D7 supports migrations based on SQL queries (indeed, at the moment that's all it supports...).

mikeryan’s picture

Version: 6.x-1.x-dev » 7.x-2.x-dev
Status: Active » Fixed

Migrate 2.0 supports flexible data sources.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.