Project

General

Profile

Actions

Patch #14593

open

migrate_from_trac.rake, print out validation errors when doing save

Added by Craig Rodrigues over 11 years ago. Updated about 11 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Importers
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

In the migrate_from_trac.rake script,
the save method is called on several objects
to save them to the database. However, if these
objects fail validation, the object is not saved to the database.
The errors are not displayed to the user, and
the migrate_from_trac.rake script will skip saving
many different objects to the database.

This patch preserves the behavior of skipping saving certain
objects if they fail validation, but the patch
will at least try to print out the errors. This will
give the user a chance to scrub the data in Trac
so that it can be properly imported into Redmine.

During my test imports of a large Trac database into Redmine,
I was wondering why certain users and certain tickets were
not being imported into Redmine.

Related to #14567


Files

migrate_from_trac.rake.txt (3.74 KB) migrate_from_trac.rake.txt Craig Rodrigues, 2013-08-01 09:52
migrate_from_trac.rake.patch.2.txt (2.68 KB) migrate_from_trac.rake.patch.2.txt Craig Rodrigues, 2013-10-13 06:28

Related issues

Related to Redmine - Patch #14567: migrate_from_trac.rake does not convert timestamps in Trac database version 23New

Actions
Actions #1

Updated by Craig Rodrigues over 11 years ago

Note, in my patch, I change this:

Time.fake(ticket.changetime) { i.save }

to:

unless i.save

In my patch for #14567 , I got rid of Time.fake,
because I found it did not work all the time and was not necessary.

I am trying to separate my patches to migrate_from_trac.rake
into smaller pieces that can be more easily reviewed and integrated into the Redmine
codebase.

Actions #2

Updated by Toshi MARUYAMA over 11 years ago

  • Related to Patch #14567: migrate_from_trac.rake does not convert timestamps in Trac database version 23 added
Actions #3

Updated by Marc Schlaich over 11 years ago

I would say the sane solution is to run the complete script in a database transaction so in case of an error everything is just rolled back. It should be a everything or nothing import strategy. see #14844

Actions #4

Updated by Craig Rodrigues about 11 years ago

Here is another version of the patch. This patch does not depend on #14567
and just adds more verbose error messages around places where it tries to save to the database.

Actions

Also available in: Atom PDF