More specifically.. I get the following errors when attempting to save the content set mapping:

user warning: BLOB/TEXT column 'sourceid' used in key specification without a key length query: CREATE TABLE migrate_map_arscustomers ( `sourceid` LONGTEXT DEFAULT NULL, `destid` INT unsigned NOT NULL, `needs_update` TINYINT unsigned NOT NULL DEFAULT 0, PRIMARY KEY (sourceid), INDEX idkey (destid) ) /*!40100 DEFAULT CHARACTER SET UTF8 */ in /home/arsretai/public_html/includes/database.inc on line 550.
# Could not analyze migrate_map_arscustomers (connection default)
# user warning: BLOB/TEXT column 'sourceid' used in key specification without a key length query: CREATE TABLE migrate_msgs_arscustomers ( `mceid` INT unsigned NOT NULL auto_increment, `sourceid` LONGTEXT 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 /home/arsretai/public_html/includes/database.inc on line 550.
# Could not analyze migrate_msgs_arscustomers (connection default)

The migrate_map tables do get identified in the table wizard but the tables are not created.

I am importing user and content profile data.

I'm really loving these Modules (table wizard, migrate and migrate extras)!

A few rough spots but overall but it's helped me out on a couple of projects in a major way! Thanks for the work in these

Bob

Comments

frankcarey’s picture

frankcarey commented
Project: Migrate Extras » Migrate
Version: 6.x-1.0-beta1 » 6.x-1.x-dev
Component: Content Profile » Code

Sounds similar to some issues I was having myself. I think this is a migrate issue though, not migrate_extras. Can you create other migrate types, like nodes? (try creating a new one).. For me, the system seemed to break and then stay broken, not allowing me to create ANY new content sets. More info you can give the better. Like what versions of migrate and migrate extras are you using?

bsnodgrass’s picture

bsnodgrass commented

I was using Migrate 6.x-1.x-dev (2010-Mar-20) and Migrate Extras 6.x-1.0-beta1 the version for Table Wizard 6.x-1.x-dev (2010-Mar-20)

I had success on another site doing something similar using Migrate 6.x-1.x-dev (2010-Mar-20) and Migrate Extras 6.x-1.x-dev (2010-Mar-25) that in combination with migrating content profile data made me suspect it was Migrate Extras.

I was able to create a new content set this time for a node, however upon attempting to import, I received the same error. I would be glad to try something else if that would help.

My next step would be to use the same dev version of migrate extras I had success with.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Status: Active » Postponed (maintainer needs more info)

Presumably you used Table Wizard to import a CSV file, and did not change any of the field types. Table Wizard creates all columns as TEXT - it's up to you to alter the MySQL columns to appropriate types (int, varchar, etc.).

bsnodgrass’s picture

bsnodgrass commented

Yes I did do this one by importing a csv file rather than an sql. The other success I had was importing an SQL so I didn't need to make those changes. That would explain it. I should be able to take another run at it in the next day or so and I will update with my results.

THANKS!

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Status: Postponed (maintainer needs more info) » Fixed

Status: Fixed » Closed (fixed)

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

xtfer’s picture

xtfer commented

I've spent 3 days looking for the solution to this one. It would be helpful to include this in the documentation (if its not already).

Leaving closed.

leenwebb’s picture

leenwebb commented

Can anyone point to some info about what exactly the Migrate module requires by way of column types for a CSV import? I understand why I'm getting this error but I'm not sure what I need to change to fix it. Does every column need to match (in type) the column it will eventually be imported into?

ensignavenger’s picture

ensignavenger commented

Hi- have you received or figured out an answer to your question yet? I too would like to know if every column type in the source table has to match every column type in the destination table?

andrewlevine’s picture

andrewlevine commented

Just in case anyone comes across this issue like I did - the fix is to make sure the primary key of your table-wizard created table is not a text field. It should be an integer or a varchar. In my case my primary key was an integer so I altered my table manually in MySQL to treat it as such:
alter table TABLENAME change column COLUMNNAME COLUMNNAME (int(11) not null);

Then my import worked fine