RT 3.4.1 upgrade oddness?

After some testing, we upgraded our main Request Tracker server from
3.2.2 to 3.4.1 and we were very pleased with the results: it went
extremely smooth and there was little to no interruption of service.

So, with that nice experience under our belt, we took on the task of
upgrading on of our clients’ installations of Request Tracker from 3.2.2
(we keep the versions in sync for ease of maintenance) to 3.4.1 and,
well, this upgrade didn’t go as smoothly. One of the upgrade scripts
(3.3.0 - schema) generated an error, but we pressed onwards.

However, now, we are seeing the following in the error_log, and
transaction body entries are not making it in to the database:
[Tue Mar 15 14:38:47 2005] [error] [client 67.160.250.30] FastCGI:
server “/opt/rt3/bin/mason_handler.fcgi” stderr:
RT::Handle=HASH(0xa6bc66c) couldn’t execute the query 'SELECT DISTINCT
main.Id AS id, main.Filename AS filename, main.ContentType AS
contenttype, main.Headers AS headers, main.Subject AS subject,
main.Parent AS parent, main.ContentEncoding AS contentencoding,
main.ContentType AS contenttype, main.TransactionId AS transactionid,
main.Created AS created FROM Attachments main , Transactions
Transactions_1, Tickets Tickets_2 WHERE ((Tickets_2.EffectiveId =
‘12557’)) AND ((Transactions_1.Ticket = Tickets_2.id)) AND
((main.TransactionId = Transactions_1.id)) ’ at
/usr/lib/perl5/site_perl/5.8.3/DBIx/SearchBuilder/Handle.pm line 494.,
referer:
http://site.org/Ticket/Update.html?Action=Comment&DefaultStatus=resolved&id=12557
[Tue Mar 15 14:38:47 2005] [error] [client 67.160.250.30] FastCGI:
server “/opt/rt3/bin/mason_handler.fcgi” stderr: DBD::mysql::st execute
failed: Unknown column ‘Transactions_1.Ticket’ in ‘where clause’ at
/usr/lib/perl5/site_perl/5.8.3/DBIx/SearchBuilder/Handle.pm line 480.,
referer:
http://site.org/Ticket/Update.html?Action=Comment&DefaultStatus=resolved&id=12557

I know a fair amount of SQL, but , after looking at the database and
getting completely lost with the aliases (Transactions_1, Tickets_2)
stuff, I figured I would toss the question out to the list to see if
anyone has an idea as to what is going on, what failed, and what I might
do to fix this?

I compared the working version of 3.4.1 with this problematic version
and I cannot see any column differences. There just isn’t a
transactions.ticket in either instance. :frowning:

Thanks!
-Rich

Richard West $14.95 Registrations mailto:rwest@wesmo.com
Wesmo Computer Services .com .net .org .tv .cc http://www.wesmo.com
Full Domain & Web Hosting .BIZ .INFO & MORE!!

So, with that nice experience under our belt, we took on the task of
upgrading on of our clients’ installations of Request Tracker from 3.2.2
(we keep the versions in sync for ease of maintenance) to 3.4.1 and,
well, this upgrade didn’t go as smoothly. One of the upgrade scripts
(3.3.0 - schema) generated an error, but we pressed onwards.

Uh. What sort of error? If your schema upgrade failed, the system
ain’t gonna work. It also sounds like you might have stale mason
templates sitting around.

Jesse

Actually, it was a warning about a duplicate column, but unfortunately I
lost it when I closed the terminal session. :frowning:

However, I think you might be right about stale stuff hanging around… I
downed the web server again, made sure that all of the mason handlers
were down, then brought up the web server. Since then, all tests have
gone through with no problems.

It looks as if the problem may have been temporary or due to a FCGI
process and subsequent mason_handler process hanging around after the
upgrade. I’m keeping eyes on things, though…

-Rich

Grr… it worked for my test tickets, but other tickets are barfing the
same way!

It seems like, for some reason, it is having problems with the column
Transactions_1.Ticket (which is an alias for Transactions.Ticket, to
which the Transactions table doesn’t have a column named Ticket!).

I have gone through the etc/upgrade/3.3.0 and etc/upgrade/3.3.11 files
by hand… everything has been applied properly. Any ideas as to the
cause of this column not existing or even being needed in the first place.

[Tue Mar 15 16:41:13 2005] [error] [client 67.160.250.30] FastCGI:
server “/opt/rt3/bin/mason_handler.fcgi” stderr:
RT::Handle=HASH(0x9b9966c) couldn’t execute the query 'SELECT DISTINCT
main.Id AS id, main.Filename AS filename, main.ContentType AS
contenttype, main.Headers AS headers, main.Subject AS subject,
main.Parent AS parent, main.ContentEncoding AS contentencoding,
main.ContentType AS contenttype, main.TransactionId AS transactionid,
main.Created AS created FROM Attachments main , Transactions
Transactions_1, Tickets Tickets_2 WHERE ((Tickets_2.EffectiveId =
‘12561’)) AND ((Transactions_1.Ticket = Tickets_2.id)) AND
((main.TransactionId = Transactions_1.id)) ’ at
/usr/lib/perl5/site_perl/5.8.3/DBIx/SearchBuilder/Handle.pm line 494.,
referer: http://site.org/
[Tue Mar 15 16:41:13 2005] [error] [client 67.160.250.30] FastCGI:
server “/opt/rt3/bin/mason_handler.fcgi” stderr: DBD::mysql::st execute
failed: Unknown column ‘Transactions_1.Ticket’ in ‘where clause’ at
/usr/lib/perl5/site_perl/5.8.3/DBIx/SearchBuilder/Handle.pm line 480.,
referer: http://site.org/

I’d hate to have to down the software to back out of the whole thing
now… :frowning:

-Rich

Jesse Vincent wrote:

rm -rf /opt/rt3/var/mason_data/obj

then stop and start apache?

That was it! I didn’t even know that directory existed… :slight_smile:

Once it was cleared out, and the web server restarted, everything
appeared to flow properly.

Thanks for your help, Jesse!
-Rich