Refactor map and message tables

This must have been a precursor to this one? http://drupal.org/node/463830

just a note: This update (6000) was timing out for me after 90 seconds. I had a quite a few content sets (10?) so that may be why, but still surprising.

Do the new map tables allow you to take advantage of views arguments to use the same view for multiple content sets?

i see you said "Also, introducing the reasonable restriction that a given view could only be the source for one content set would eliminate the need for the mcsid column in map tables, and the need to include the destination type in the map and message table names"

I created a new content set and It looks like the map and msg table names are now being created using the mscid ("migrate_map_27"), so that in my mind would mean that YES, one view could be used as the basis for multiple content sets. This differs however from what update 6000 seemed to do because my existing map tables are all in the format "migrate_map_myviewname".

I'm getting a couple errors after saving my new content set:

* Could not analyze migrate_map_27 (connection default)
* Could not analyze migrate_msgs_27 (connection default)

Probably because the tables aren't being created.

For the new tables, I'm getting this error in my logs:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DEFAULT NULL, `level` INT unsigned NOT NULL DEFAULT 1, `message` MEDIUMTEXT NO' at line 3 query: update_sql /* admin : update_sql */ CREATE TABLE migrate_msgs_30 ( `mceid` INT unsigned NOT NULL auto_increment, `sourceid` DEFAULT NULL, `level` INT unsigned NOT NULL DEFAULT 1, `message` MEDIUMTEXT NOT NULL, PRIMARY KEY (mceid), INDEX sourceid (sourceid) ) /*!40100 DEFAULT CHARACTER SET UTF8 */ in /var/www/devroots/d6-matadortravel-com/includes/database.inc on line 529.

The query works if I re-run the query with INT for the type. Is it missing?

I think this is related to use of external tables only, because if i use a view based on a local table it seems to work fine. Looks like some lookup of the primary key's type is failing and not being passed in the query above?

Traced it back to the schema_mysql_inspect() call (aliased by a schema_invoke('inspect') call in migrate.module)

schema_mysql_inspect() looks up all the tables in the database. Since once the external tables are defined in hook_views_data() by tw as having a 'default' database, when the schema_mysql_inspect() get's called, it's not going to be one of the tables listed because it doesn't really exist in that database.

I'm thinking a small patch to this might check for presence of a period in the table name and then overwrite the table and database values and continue as normal.

OK, this is what i've got so far in migrate.module:

   $tablename = $view->base_table;
   // Tw can treat external mysql tables as internal, but we can revert
   // if we find a period in the tablename.
   if (strpos($tablename, '.')) {
     list($tabledb, $tablename) =  explode('.', $tablename);
   }
   $inspect = schema_invoke('inspect');
   db_set_active('default');
   $sourceschema = $inspect[$tablename];

But,I think the problem now is that $tabledb is the actual db name, not the alias from settings.php, so we'll have to get that back... driving on.

Yes, the problem was that i had some sort of hybrid code, and now the new functionality is showing up for me. RE #9 - #12: the patch in #661934: Allow migrate to handle external tables. is still needed to get external tables working (and the tw patch it depends on)