Failing to Migrate from Mantis
Added by Alan Chandler over 12 years ago
I have just installed a fresh version of Redmine from the stable download (ie 1.3.2) on a Debian Squeeze system running Apache. This contains Ruby 1.8.6 and Rails 2.3.5. I also installed gems (1.3.7) and rake (0.8,7) from the standard distribution.
For the migration only, I installed libmysql-ruby (2.8.2), as my main configuration has been set to run a sqlite3 database.
I followed installation instructions both from this web site getting as far as successfully completing
RAILS_ENV=production rake redmine:load_default_data
And the successfully checking with
ruby script/server webrick -e production
Before going any further I tried to migrate from an existing Mantis Solution I have set up
rake redmine:migrate_from_mantis RAILS_ENV="production"
and after entering the database credentials for my Mantis installation, I got the following
Migrating users......
rake aborted!
SQLite3::SQLException: columns project_id, tracker_id are not unique: INSERT INTO "projects_trackers" ("project_id", "tracker_id") VALUES (1, 1)
Before trying this, I also tried with a fresh installation installing the mantis2redmine plugin, but when I tried to use it, it just died on me, so had no idea what was happening. I completely blew that installation away and started again.
I am brand new to Ruby/Rails and Redmine, so I don't really know what I am doing - I am trying to set up an evaluation to see whether I should migrate from Mantis, but I seem to have fallen at the first hurdle.
Can someone tell me where I am going wrong, and how to complete a migration.
Thanks
Replies (4)
RE: Failing to Migrate from Mantis - Added by Alan Chandler over 12 years ago
I am starting to look at this to try and figure out for myself what is going wrong, but I am stuck
Looking carefully at the output produced so far it says "Migrating Users" followed by 6 dots. This matches what I have found in my sqlite database. Namely there are now 7 users, the original admin user and the 6 from my Mantis database.
But the code then seems to output something else which doesn't appear.
print "Migrating users" User.delete_all "login <> 'admin'" users_map = {} users_migrated = 0 MantisUser.find(:all).each do |user| u = User.new :firstname => encode(user.firstname), :lastname => encode(user.lastname), :mail => user.email, :last_login_on => user.last_visit u.login = user.username u.password = 'mantis' u.status = User::STATUS_LOCKED if user.enabled != 1 u.admin = true if user.access_level == 90 next unless u.save! users_migrated += 1 users_map[user.id] = u.id print '.' end puts # Projects print "Migrating projects"
namely "Migrating projects" Which as you can see from my dump of the problem above doesn't happen
So why - does Ruby/Rails buffer output, and its not flushed on the error? It certainly looks like the error occurs in Migrating the first project.
However when I look at the database there is already 1 project in there and if I look at table projects_trackers it already has 3 entries
1,1
1,2
1,3
Which I am presuming is a result of the following lines in the code
next unless p.save projects_map[project.id] = p.id p.enabled_module_names = ['issue_tracking', 'news', 'wiki'] p.trackers << TRACKER_BUG p.trackers << TRACKER_FEATURE print '.'
However again I am puzzled - I think p.trackers << TRACKER_BUG
creates the 1,1 entry and the p.trackers << TRACKER_FEATURE
creates the 1,2 entry, but where does the 1,3 entry come from (and again I assume some output is buffered because '.' hasn't yet come).
The next piece of the code seems to create entries in what I assume is the members table. THIS TABLE IS EMPTY in my database after the crash, so I am assuming we didn't get that far.
# Project members project.members.each do |member| m = Member.new :user => User.find_by_id(users_map[member.user_id]), :roles => [ROLE_MAPPING[member.access_level] || DEFAULT_ROLE] m.project = p m.save end
Am I correct?
RE: Failing to Migrate from Mantis - Added by Alan Chandler over 12 years ago
I think I am getting there, having now discovered the --trace option.
The exception is created on this line
p.trackers << TRACKER_BUG
(line 274 in the migrate_from_mantis.rake file in lib/tasks/)
which is part of this little run
next unless p.save projects_map[project.id] = p.id p.enabled_module_names = ['issue_tracking', 'news', 'wiki'] p.trackers << TRACKER_BUG
As I said, I don't fully understand how rails/ruby works - and perhaps more particularly how ActiveRecord::Base works but as far as I can workout p.save returns false when it fails validation.
Looking through the app/models/project.rb file I came across
validates_associated :repository, :wiki
at line 74. Since the wiki link has not yet been set on the record then it fails validation. Am I correct? (and if I am then why bother with the next unless p.save
?)
Finally at line 102
if !initialized.key?('trackers') && !initialized.key?('tracker_ids') self.trackers = Tracker.all end
Seems to me to say if when I initially do the
p = Project.new :name => encode(project.name), :description => encode(project.description)
at line 268 of the migrate script, that if I haven't set the key 'trackers' then I will automatically create all the possible trackers that there are.
If all my postulation is correct, then what is happening is that I create a new "projects" record and for that record I then create all possible records in "projects_trackers" table and then try and create a new one with the p.trackers << TRACKER_BUG
statement and I therefore fall over with an unique index exception.
- The project I migrated is set private, yet the migrated project is public.
- The "identifier" column of the projects table seems to have been set to the later characters of the project name rather than the first - not sure if this matters but it seems strange
Now the question becomes how do I fix it.
I presume that we have to leave app/models/project.rb as is. Therefore- We need to create the two trackers TRACKER_BUG and TRACKER_FEATURE as part of the new statement
- I wonder if the
next unless p.save
is trying to validate the names called in from Mantis for length and or uniqueness (although I can't see how) and therefore wonder if it can be removed
I'll try and teach myself some more ruby to have a go, although any help from more experienced users would be more welcome.
RE: Failing to Migrate from Mantis - Added by Alan Chandler over 12 years ago
I reported this as an issue #10501, and have offered a patch to fix it in that issue.
I now have another problem, further down the project migration code, with a failure to convert dates of versions. (I think Mantis is using an integer to hold seconds since 1970, not sure what redmine wants).
The code in question is
# Project versions project.versions.each do |version| v = Version.new :name => encode(version.version), :description => encode(version.description), :effective_date => (version.date_order ? version.date_order.to_date : nil) v.project = p
It appears version.date_order.to_date
doesn't exist according to the error message I get
I've reported this problem as #10504
RE: Failing to Migrate from Mantis - Added by Alan Chandler over 12 years ago
I eventually solved this with the patch in issue #10532
Does anyone here have any better way of getting support. No one has replied to this forum post, and its already on the second page and therefore would have been forgotten for ever. No one responded or even acknowledged any of the issues I raised in the issue list. A big piece of this application seems to be full of bugs that nobody cared about!.
As an outsider it makes me very nervous that I am going to be depending on it.
Or am I just looking in the wrong place?