The reason the tables were not being created was that external tables obviously weren't showing up on the schema_mysql_inspect() calls on the 'default' database. BUT I just added a patch to over at #610128: Can't add external and internal tables' columns to the same view which is needed to get this working with migrate (and migrating content from external databases joined to internal ones IS working finally!).

If you read my synopsis at #576694: Enable views to handle external tables properly, allowing for joins across tables in different mysql databases, the only way to take advantage of this mysql ability to join across databases in views is to change the db of the external table to 'default' and then name the external table using [ext_database].[ext_table] This patch basically just uses the new function tw_inspect_schema() from the tw patch above and checks to see if a table has a period in it. If it does, it extrapolates the actual database and table names from the 'hyphenated' external tablename in views ([ext_database].[ext_table]) and then is able to get the schema correctly since it's now acting like a proper table in an external database.

With this patch, the external + internal table views I had setup with tw module now work properly in migrate as well. So this should complete the cycle to using external and internal tables to generate views, and then using those views as the base for a content set.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

frankcarey’s picture

NOTE: this requires this tw patch to work http://drupal.org/node/610128#comment-2383238

frankcarey’s picture

The old file was crap (and based on my hybrid code). This one is truely based on the Dec 15th dev snapshot :)

frankcarey’s picture

I removed the static variable too. Probably best to add it to the tw_inspect_schema() function, probably paired with a pared down schema_mysql_inspect call so that only the table in question is retrieved not the whole db structure, keeping the static variable a minimal size.

mikeryan’s picture

Status: Needs review » Needs work

Just a note that I'm aware of this, haven't got around yet to making it suitable for commit (it needs to fallback to the old code if the TW and Views enhancements it depends on aren't present, and the static cache is essential).

frankcarey’s picture

maybe i should replace tw_inspect_schema() with migrate_inspect_schema() instead? that way we are sure that they are coupled together, and no other module but migrate uses that function anyway. (I probably should have done this originally)

The views enhancement isn't a requirement because this works in the opposite way. Migrate just gets the tablename from the view and runs migrate(tw)_inspect_schema() on the tablename / database. It's new feature is just to be able to interpret the right tablename and database to use for the schema_inspect call for tablenames with a period in it, but if there is no period, it runs it normally. TW won't add periods to tablenames unless the views enhancements are available, so the check is already done.

How do you like the static var ideas in #3? I think it would be good to inspect just the table in question, not the whole database as is done now. I foresee a structure like so for the static variable:

$schema = array(
  'default' => array(
    'table1' => array(
      //schema info
    ),
    'externaldb.table1' => array(
      //schema info
    ),
  ),
  'database2' => array(
    'table1' => array(
      //schema info
    ),
  ),
);

so it could easily look up any external tables it finds within a view.

mikeryan’s picture

Status: Needs work » Fixed

OK, I've committed this, moving the inspection function from TW to migrate and caching at the DB level.

Thanks!

Status: Fixed » Closed (fixed)

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