The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.When processing a content set I'm not getting a map table because the source primary key is always zero:
user warning: Duplicate entry '0' for key 'PRIMARY' query: INSERT INTO member_user_map (MemID, userid, mcsid) VALUES(0, 4200, 3) in /home/robert/docroot/alzforum.org/trunk/docroot/sites/all/modules/migrate/supported/user.inc on line 142.
mysql> describe member_user_map; +--------+------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------+------------------+------+-----+---------+-------+ | MemID | varchar(38) | NO | PRI | NULL | | | userid | int(10) unsigned | NO | MUL | NULL | | | mcsid | int(10) unsigned | NO | | NULL | | +--------+------------------+------+-----+---------+-------+ mysql> select * from migrate_content_sets; +-------+-----------+-----------+-------------+----------+-------------+----------+-----------+----------+---------------------+--------+----------+ | mcsid | view_name | sourcekey | contenttype | desttype | description | clearing | importing | scanning | lastimported | weight | rowcount | +-------+-----------+-----------+-------------+----------+-------------+----------+-----------+----------+---------------------+--------+----------+ | 3 | member | MemID | user | 2 | Users | 0 | 0 | 0 | 2009-05-15 19:02:58 | 0 | 0 | +-------+-----------+-----------+-------------+----------+-------------+----------+-----------+----------+---------------------+--------+----------+ 1 row in set (0.00 sec)
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | hook_schema.patch | 6.81 KB | robertdouglass |
Comments
Comment #1
mikeryanAhhh, I neglected to add a task for this when first populating the issue queue - the migrate module assumes the primary key of the source is an integer, it needs to be extended to handle (at least) strings when managing the map and message tables. You can see note of this, and a hack for a couple of specific instances I needed, in supported/node.inc starting at line 75.
Comment #2
robertdouglass commentedOk. I'll see if I can roll a patch.
Comment #3
robertdouglass commentedMike, every *.inc file ends up with some code like this:
There are a couple ways I see to approach the fix. I could use schema_invoke('inspect') to get the schema information and then change %d to %s or something appropriate. I could even abstract this bit to a maptable_write() function so that integration .inc's don't have to handle the introspection. Or I could put a field in the database that says what type the primary key is for the source database table. In this case, I could put it in either migrate_content_mappings or migrate_content_sets. To my eye, migrate_content_mappings looks like the better place. I'd lean towards adding a column to migrate_content_mappings so that we don't have to inspect the table any more. What do you suggest?
Comment #4
robertdouglass commentedDifferent approach. I implemented hook_schema and we now have dynamic schema information available for the mapping tables. This lets us use drupal_write_record. Note the code still should be factored out of the .inc files, which I've noted with TODOs. node.inc and comment.inc are untested. user.inc works with 38 varchar keys.
Comment #5
robertdouglass commentedNote also that hook_schema itself is completely copied code which might also be an opportunity for refactoring.
Comment #6
robertdouglass commentedMike, let me know if you've got feedback about this issue. In relation to all of the other bugs I see in the queue this one is the most critical (at least for any project that has non integer keys). Thus I'm boosting the Priority.
Comment #7
mikeryanWorking towards this, I've added a new API function, migrate_add_mapping() for the hooks to use to update the map table. For now it's still assuming integer keys, but the next steps are:
1. migrate_save_content_set() creates (or updates, as necessary) the map table to use int or varchar as appropriate for the sourceid.
2. migrate_add_mapping uses %d or '%s' as appropriate.
Comment #8
robertdouglass commentedMike, I think my solution of adding hook_schema for the tables is a better option. drupal_write_record is there specifically so that we don't have to add logic to the code to switch between %d and %s. I do wonder, though, if the hook_schema implementation should be in the table wizard module instead.
Comment #9
mikeryanThe central function will be an aid, whether or not schema is used.
I had thought of adding tables to the schema a long time ago, and rejected it for reasons I can't quite recall. I'll take a close look at your proposal when I have the time (maybe tomorrow) and try to figure it out...
Comment #10
mikeryanOK, I've committed your patch (updated to work with subsequent refactoring). The map table is now handled properly with a text key in the source - however, I still need to deal with the messages table properly.
Thanks.
Comment #11
mikeryanAll right, same approach to the msgs table (adding to schema, using drupal_write_record). Should be all done, let me know if you have any trouble...
Comment #12
robertdouglass commentedNice, thanks!