Lost of history after upgrade from 3.0.11 to 3.4.2

Hello,

i made an upgrade from RT 3.0.11 to 3.4.2. I use a test server.
I have respected the procedure, doing a “make upgrade” and executing the
database uptade sripts, but the history doesn’t appear in the view of
tickets.
Can anybody help me please ?

i made an upgrade from RT 3.0.11 to 3.4.2. I use a test server.
I have respected the procedure, doing a “make upgrade” and executing the
database uptade sripts, but the history doesn’t appear in the view of
tickets.
Can anybody help me please ?

Don’t know if I can help, but I’m in a similar situation (RT3.2.3->3.4.2 w/
local customizations). The upgrade ran fine (using both a parallel install and
the ‘make upgrade’ path), but I can’t see ticket histories. Reading the list and
changelogs, it seems like database upgrades should do the trick (or at least
have worked for other folks). I haven’t run the upgrades for fear of mangling
our ticket databse – is this a legitimate concern? Should I feel comfortable
upgrading the objects straight away or is a backup necessary?

Will Maier

Will Maier wrote:

i made an upgrade from RT 3.0.11 to 3.4.2. I use a test server.
I have respected the procedure, doing a “make upgrade” and executing the
database uptade sripts, but the history doesn’t appear in the view of
tickets.
Can anybody help me please ?

Don’t know if I can help, but I’m in a similar situation (RT3.2.3->3.4.2 w/
local customizations).

Have you tried moving your local customizations out of the way? Then
stop apache, empty the mason cache, and start apache. From what I
recall of my short 3.4.x test period, something I had done locally
caused a similar problem.

The upgrade ran fine (using both a parallel install and
the ‘make upgrade’ path), but I can’t see ticket histories. Reading the list and
changelogs, it seems like database upgrades should do the trick (or at least
have worked for other folks). I haven’t run the upgrades for fear of mangling
our ticket databse – is this a legitimate concern? Should I feel comfortable
upgrading the objects straight away or is a backup necessary?

Drew Barnes
Applications Analyst
Raymond Walters College
University of Cincinnati

If you check out the README there is a section that will explain that
there are 3 separate scripts that you need to run. I dont have the
information in front of me but it was pretty easy to figure out once
you find it in the upgrade notes. I was having the same issue when I
upgraded, couldnt see History but after I ran the scripts it was fine.On 7/25/05, Will Maier willmaier@ml1.net wrote:

On Mon, Jul 25, 2005 at 10:51:32AM +0200, ogigondan@coframi-toulouse.com wrote:

i made an upgrade from RT 3.0.11 to 3.4.2. I use a test server.
I have respected the procedure, doing a “make upgrade” and executing the
database uptade sripts, but the history doesn’t appear in the view of
tickets.
Can anybody help me please ?

Don’t know if I can help, but I’m in a similar situation (RT3.2.3->3.4.2 w/
local customizations). The upgrade ran fine (using both a parallel install and
the ‘make upgrade’ path), but I can’t see ticket histories. Reading the list and
changelogs, it seems like database upgrades should do the trick (or at least
have worked for other folks). I haven’t run the upgrades for fear of mangling
our ticket databse – is this a legitimate concern? Should I feel comfortable
upgrading the objects straight away or is a backup necessary?

Will Maier


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

-Juan

Will Maier wrote:

Don’t know if I can help, but I’m in a similar situation (RT3.2.3->3.4.2 w/
local customizations).

Have you tried moving your local customizations out of the way? Then
stop apache, empty the mason cache, and start apache. From what I
recall of my short 3.4.x test period, something I had done locally
caused a similar problem.

The local customizations predate me and don’t make use of the overlay model, so
I’d have a hard time fully separating the two. That said, the modifications are
relatively minor; I have commented out important portions of the more
significant mods earlier in the upgrade path in order to resolve minor errors
related to rendering.

All the research I’ve done so far suggests that our database (built for 3.2.3)
needs to be updated for the 3.4.2 release. While it’s possible that our mods to
RT remain a problem, the problem itself (no history) seems similar to issues
reported to this list and elsewhere that were subsequently resolved by database
updates.

See other subthread for comments on that issue…

Thanks

Will Maier

If you check out the README there is a section that will explain that
there are 3 separate scripts that you need to run. I dont have the
information in front of me but it was pretty easy to figure out once
you find it in the upgrade notes. I was having the same issue when I
upgraded, couldnt see History but after I ran the scripts it was fine.

I read the README – my question was more concerned with the safety/efficacy of
the database upgrade scripts. From your message, it sounds like you didn’t
experience any data loss during the database upgrade. If this is so, I’ll be
much more comfortable running the upgrade. Any chance the scripts will break
exisitng databases? I’m inclined to trust them, but positive/negative
experiences would be welcome data points.

Will Maier

I read the README – my question was more concerned with the safety/efficacy of
the database upgrade scripts. From your message, it sounds like you didn’t
experience any data loss during the database upgrade. If this is so, I’ll be
much more comfortable running the upgrade. Any chance the scripts will break
exisitng databases? I’m inclined to trust them, but positive/negative
experiences would be welcome data points.
The upgrade scripts are rather straightforward, and I’ve yet to hear of
major problems with them. You can look at the sql that they run
yourself, if you want to reassure yourself; they’re in:
etc/upgrade/3.3.*/{acl,schema}.databasetype

  • Alex

I read the README – my question was more concerned with the safety/efficacy of
the database upgrade scripts. From your message, it sounds like you didn’t
experience any data loss during the database upgrade. If this is so, I’ll be
much more comfortable running the upgrade. Any chance the scripts will break
exisitng databases? I’m inclined to trust them, but positive/negative
experiences would be welcome data points.

The upgrade scripts are rather straightforward, and I’ve yet to hear of
major problems with them. You can look at the sql that they run
yourself, if you want to reassure yourself; they’re in:
etc/upgrade/3.3.*/{acl,schema}.databasetype

Thanks for the feedback. The only trouble is that I’m running two parallel
instances of RT (and Apache), one for testing 3.4.2 and one production 3.2.3.
My concern is that the update scripts required to get the testing instance
running correctly might break the database which the production instance depends
upon.

The wiki touches on these issues, but doesn’t address database upgrades and
their impact on concurrent testing/production installs of RT.

Will Maier

I had already ran the scripts.
However, i have resolved the problem running once again the scripts, but
changing the version at the end of the command line. I choose the “3.3.0”.

Hello,

i want to realize statistics for RT. I have installed the plugin, but i
have to install the GD::Graph perl module and i have some problems.
Using the command : “perl -MCPAN -e ‘install GD::Graph’” i had errors and
it say to me to use the option “force” so i use the command:
“perl -MCPAN -e ‘force install GD::Graph’”. Now when i re-run the first
command, it say that the module is up to date. However when i want to use
the statistics in RT i don’t see the images and have some errors. The
first is:
"Can’t locate GD.pm in @INC"
Can i have help please ?

ogigondan@coframi-toulouse.com wrote:

“Can’t locate GD.pm in @INC

Install GD via CPAN?

Will Maier wrote:

My concern is that the update scripts required to get the testing instance
running correctly might break the database which the production instance depends
upon.

They shouldn’t, if you’ve supplied the right database to
configure (–with-db-database). You should be running
rt-setup-database out of your installed testing instance,
so it won’t know anything about the production instance.

“make upgrade-instruct” tells you what you need to do.

Of course, paranoia is a Good Thing, and backups before
making significant change are always a Good Idea. :slight_smile:

Will Maier wrote:

My concern is that the update scripts required to get the testing instance
running correctly might break the database which the production instance depends
upon.

They shouldn’t, if you’ve supplied the right database to
configure (–with-db-database). You should be running
rt-setup-database out of your installed testing instance,
so it won’t know anything about the production instance.

Only problem is that the two instances share the database right now; sorry for
not being clear on that point. I’d go ahead and mirror the current database, but
we’re a little tight on resources – a third mysqldb on the server would be a
Bad Thing. My problem is that I want to guarantee the upgrade as much as I can;
at the same time, I feel limited by hardware and system design concerns (neither
of which are RT’s fault).

Maybe a more appropriate question might be: how are folks testing their
upgrades? Anyone in a similarly unfortunate situation?

Of course, paranoia is a Good Thing, and backups before
making significant change are always a Good Idea. :slight_smile:

Amen; sorry to let my paranoia (Good Thing or otherwise) fill up a thread.
Thanks for your reply.

Will Maier