projectknife / Migrator

Projectfork 3 to 4 migration extension.
1 stars 4 forks source link

13. Migrating Repository Folders - Duplicate entry #6

Closed bembelimen closed 11 years ago

bembelimen commented 11 years ago

Hello,

the migration works till point 13. There I get the following error:

PFTableDirectory: :store failed
Duplicate entry '69' for key 'PRIMARY' SQL=INSERT INTO jos_pf_repo_dirs (parent_id,level,lft,rgt,alias,project_id,title,description,created,created_by,attribs,access,protected) VALUES ('463','3','39','40','xxxxxx','3','XXXXXX','','2013-07-17 11:04:07','763','{}','6','0')

The original entry (from the old tables) has an ID of 457.

simjuande commented 11 years ago

pftables

check my error there i just filter in my database for searching %Itamar Email Campaign% this data, i found 2 tables that have the same data in "j25_pf_folders", "jos_pf_folders" so i just delete it.. and then i migrate again it smoothly finished. but before i got in number 13 process i encounter 4 duplicates... hope it helps

bembelimen commented 11 years ago

The problem is/was, that the migration component saves the directories first with the standard (auto increment) id and after updates the id to the old one (from projectfork 3). But the auto increment value will not be updated, so with enouth directories, there will be a conflict. Solution (as quickfix, I guess not very clean): admin/models/repodirs.php add in line 254:

    // Change the auto_increment value
    $this->_db->setQuery('ALTER TABLE #__pf_repo_dirs AUTO_INCREMENT =1');
    $this->_db->execute();
eaxs commented 11 years ago

The problem is/was, that the migration component saves the directories first with the standard (auto increment) id and after updates the id to the old one (from projectfork 3). But the auto increment value will not be updated, so with enouth directories, there will be a conflict.

This observation is correct. However, I went a different way to solve the problem because the ALTER TABLE rebuilds the whole table - which is as you said not very clean. Instead, I'm taking the highest ID of the old table, insert it into the new one and then delete it again when the migration starts to artificially raise the auto_inc value.