3.5.0 Database upgrade scripts

I just attempted to update from 3.4.5 to 3.5.0, and the database update schema (version 14) failed on line 1. I am running mysql 5.0.45. I changed the script to the following and it seems to work fine:

file 14/openfire_mysql.sql

# jiveRoster: Change jid column to varchar
ALTER TABLE jiveRoster MODIFY jid VARCHAR(1024) NOT NULL; # jiveRoster: Add new index
ALTER TABLE jiveRoster ADD INDEX jiveRoster_jid_idx (jid); UPDATE jiveVersion SET version=14 WHERE name = 'openfire';

Anyone else run into issues with this?

Hrm. The original statement worked wonderfully on my installs. Wonder if something was changed in MySQL that you are running into? I’ll investigate this and possibly get this into 3.5.1. Thanks for the updated script!

I’m definitely not a MySQL expert, but the new script seems to work for me. I would definitely suggest testing it on several setups to make sure it works across the board, though

I think this happened to me too (going from 3.4.5 to 3.5) I’ve never actually looked in the resources/database/upgrade directories until I saw this forum post. But the stock rpm -Uvh on a RedHat EL (v5) (mysql 5.0.22) box appeared to work fine, admin console was fine, but I wasn’t seeing other sessions from a standard client connection and there were db errors in the error.log.

jiveVersion(name = openfire) was/is at 13 - so I’m assuming it bombed out on me there too.

I downgraded back to 3.4.5 which worked a-ok. And need to go back to my test server setup before I try this one again

I’ve got a slightly non-standard db setup, I’m using a jdbcProvider to point into another db for authentication/user information, so it’s probably something in my db throwing things, but this is the first straight up rpm -Uvh that’s failed on me in a while.

http://dev.mysql.com/doc/refman/5.1/de/alter-table.html

| ALTER [COLUMN] col_name {SET DEFAULT literal | DROP DEFAULT}
| CHANGE [COLUMN] old_col_name column_definition
        [FIRST|AFTER col_name]

=> use CHANGE or MODIFY.

Where is MODIFY coming from? I don’t see it in the definition. I’ll be happy to change it to CHANGE though since that’s what’s showing. Wonder why ALTER works for me? =) I’ll get that changed.

JM-1315

BenV wrote:

I’m definitely not a MySQL expert, but the new script seems to work for me. I would definitely suggest testing it on several setups to make sure it works across the board, though

chuckle Sometimes it feels like dealing with Internet Explorer. =) I did test it on a couple of setups btw, apparently not enough.

jayoungncsu wrote:

I think this happened to me too (going from 3.4.5 to 3.5) I’ve never actually looked in the resources/database/upgrade directories until I saw this forum post. But the stock rpm -Uvh on a RedHat EL (v5) (mysql 5.0.22) box appeared to work fine, admin console was fine, but I wasn’t seeing other sessions from a standard client connection and there were db errors in the error.log.

jiveVersion(name = openfire) was/is at 13 - so I’m assuming it bombed out on me there too.

I downgraded back to 3.4.5 which worked a-ok. And need to go back to my test server setup before I try this one again

I’ve got a slightly non-standard db setup, I’m using a jdbcProvider to point into another db for authentication/user information, so it’s probably something in my db throwing things, but this is the first straight up rpm -Uvh that’s failed on me in a while.

Hi Jason! The non-standard db setup -shouldn’t- be causing any problems. It looks like upgrade script 14 is just … well working on some MySQLs and not on others. Gotta love consistency! You should be able to make the same mods to the database scripts as these folk are. I’d suggest changing “resources/database/upgrade/14/openfire_mysql.sql” from ALTER TABLE … ALTER COLUMN to ALTER TABLE … CHANGE COLUMN.

jadestorm wrote:

Where is MODIFY coming from?

Its the line below CHANGE in the definition, I had not quoted it.

Here it is:

| MODIFY [COLUMN] column_definition [FIRST|AFTER col_name]

The difference between CHANGE and MODIFY is that you also can rename a column with CHANGE. CHANGE should be equivalent to MODIFY if you write the column name twice.

Take a look in the manual, then it should be clear:

http://dev.mysql.com/doc/refman/5.1/de/alter-table.html

Excellent, thanks Coolcat! Color me mystified how I ended up choosing ALTER COLUMN. I was staring right at that document too. And of course double mystified that it worked!

Hi Daniel! - Second attempt after editing the sql file seemed to work great. I had some oddities where Adium’s initial connection came up as “offline” only - and s2s connections seemed to take awhile to be re-established - similar to some of the other threads I’ve read (and I haven’t had time to trace better) Very happy with the admin console improvements and very much looking forward to some of the new open-sourced enterprise features (which hopefully will be a gateway drug for seeing about getting clearspace going for our team(s) )

This fix worked for me.