[rt-users] rt2tort3 import errors
Dominic Hargreaves
dominic.hargreaves at oucs.ox.ac.uk
Tue Nov 3 13:12:58 EST 2009
On Tue, Nov 03, 2009 at 11:30:17AM -0500, Jesse Vincent wrote:
> > I'm completely failing to make any sense of the error here:
> >
> > Couldn't set EffectiveId: That is already the current value
>
> Next step, I think, is to get RT to log stack traces for errors:
>
> http://wiki.bestpractical.com/view/LogsConfig has instructions.
> With that, we may have a better idea of what's going wrong.
*nod*
Here's the same error again with stack traces turned on:
t-1395038: w[Tue Nov 3 17:19:23 2009] [crit]: Couldn't set EffectiveId: That is already the current value (/usr/share/request-tracker3.8/lib/RT/Ticket_Overlay.pm:500)
Trace begun at /usr/share/request-tracker3.8/lib/RT.pm line 300
Log::Dispatch::__ANON__('Log::Dispatch=HASH(0x34207e0)', 'Couldn\'t set EffectiveId: That is already the current value') called at /usr/share/request-tracker3.8/lib/RT/Ticket_Overlay.pm line 500
RT::Ticket::Create('RT::Ticket=HASH(0x7511ba8)', 'Status', 'resolved', 'Queue', 'xxxx', 'Started', '2009-10-12 15:12:59+00', 'Starts', '1970-01-01 00:00:00+00', '_RecordTransaction', 0, 'id', 1395038, 'LastUpdated', '2009-10-12 15:13:00+00', 'Requestor', 'ARRAY(0x80c5e88)', 'Subject', 'xxxx', 'Creator', undef, 'Owner', undef, 'LastUpdatedBy', undef, 'EffectiveId', 1395038, 'Resolved', '2009-10-12 15:12:59+00', 'Created', '2009-09-27 18:07:14+00', 'Due', '2009-09-27 18:07:14+00') called at dumpfile-to-rt-3.0 line 695
RT::import_tickets at dumpfile-to-rt-3.0 line 89
Couldn't create TICKET: Ticket could not be created due to an internal error$VAR1 = {
'Status' => 'resolved',
'Queue' => 'xxxx',
'Started' => '2009-10-12 15:12:59+00',
'Starts' => '1970-01-01 00:00:00+00',
'_RecordTransaction' => '0',
'id' => '1395038',
'LastUpdated' => '2009-10-12 15:13:00+00',
'Requestor' => [
'132522'
],
'Subject' => 'xxxx',
'Creator' => undef,
'Owner' => undef,
'LastUpdatedBy' => undef,
'EffectiveId' => '1395038',
'Resolved' => '2009-10-12 15:12:59+00',
'Created' => '2009-09-27 18:07:14+00',
'Due' => '2009-09-27 18:07:14+00'
};
[Tue Nov 3 17:19:23 2009] [crit]: Died at ./dumpfile-to-rt-3.0 line 700. (/usr/share/request-tracker3.8/lib/RT.pm:387)
Trace begun at /usr/share/request-tracker3.8/lib/RT.pm line 300
Log::Dispatch::__ANON__('Log::Dispatch=HASH(0x34207e0)', 'Died at ./dumpfile-to-rt-3.0 line 700.^J') called at /usr/share/request-tracker3.8/lib/RT.pm line 387
RT::__ANON__('Died at ./dumpfile-to-rt-3.0 line 700.^J') called at dumpfile-to-rt-3.0 line 700
RT::import_tickets at dumpfile-to-rt-3.0 line 89
Died at ./dumpfile-to-rt-3.0 line 700.
If I try to insert the same ticket manually, things seem to proceed
without incident:
#!/usr/bin/perl
use strict;
use warnings;
use lib ("/usr/share/request-tracker3.8/lib");
use RT::Interface::CLI qw(CleanEnv GetCurrentUser GetMessageContent loc);
use RT::Tickets;
use RT::Template;
use RT::CustomFields;
use RT::Principals;
use RT::Scrips;
CleanEnv();
RT::LoadConfig();
RT::Init();
$RT::LogStackTraces = 1;
my $tick_object = RT::Ticket->new($RT::SystemUser);
my $ticket = {
'Status' => 'resolved',
'Queue' => 'xxxx',
'Started' => '2009-10-12 15:12:59+00',
'Starts' => '1970-01-01 00:00:00+00',
'_RecordTransaction' => '0',
'id' => '1395038',
'LastUpdated' => '2009-10-12 15:13:00+00',
'Requestor' => [
'132522'
],
'Subject' => 'xxxx',
'Creator' => undef,
'Owner' => undef,
'LastUpdatedBy' => undef,
'EffectiveId' => '1395038',
'Resolved' => '2009-10-12 15:12:59+00',
'Created' => '2009-09-27 18:07:14+00',
'Due' => '2009-09-27 18:07:14+00'
};
$tick_object->Create( %{$ticket} );
rt-migrate at steely-glint:~$ ~dom/test-create
Name "RT::LogStackTraces" used only once: possible typo at /home/dom/test-create line 19.
rt-migrate at steely-glint:~$
(and the ticket is created in the database).
the error comes from the second argument returned by $self->__Set
in Ticket_Overlay.pm, which is in turn from DBIx::SearchBuilder::Record:
I simply cannot see how that error could occur when creating a new
ticket in Ticket_Overlay.pm, reading through the logic.
Ticket.pm creates the ticket defaulting EffectiveId to 0, and
Ticket_Overlay.pm then tries to set it to the EffectiveId to that
is given in the arguments to Create, which is not 0.
The plot thickens (and it's time for me to go home :)
--
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
More information about the rt-users
mailing list