11 June 2009, 10:52

I cant search the forum and find the previous post a colleage made so I am creating a new one.

 We have tried many times and to many different versions to upgrade to 1.09 and the upgrade keeps failing, I even did it on a latest mysql built from source and that failed too!

 First we get this:

Call stack (most recent first):

• execute_sql("CREATE TABLE grouptype_cron ( plugin VARCHAR(2...", true) at /srv/www/mahara-1.1.3/htdocs/lib/dml.php:1360
• execute_sql_arr(array(size 2), true, true) at /srv/www/mahara-1.1.3/htdocs/lib/ddl.php:599
• create_table(object(XMLDBTable)) at /srv/www/mahara-1.1.3/htdocs/lib/db/upgrade.php:348
• xmldb_core_upgrade("2008040218") at /srv/www/mahara-1.1.3/htdocs/lib/upgrade.php:271
• upgrade_core(object(stdClass)) at /srv/www/mahara-1.1.3/htdocs/admin/upgrade.json.php:71

 Then when we go back to admin/upgrade.php we get this:

Call stack (most recent first):

• execute_sql("ALTER TABLE {group} ADD grouptype CHARACTER VARYIN...") at /srv/www/mahara-1.1.3/htdocs/lib/db/upgrade.php:165
• xmldb_core_upgrade("2008040218") at /srv/www/mahara-1.1.3/htdocs/lib/upgrade.php:271
• upgrade_core(object(stdClass)) at /srv/www/mahara-1.1.3/htdocs/admin/upgrade.json.php:71

 What do you suggest, I looked up the errno for mysql and it said something about not being able to create a table with a foreign key in innodb.  any thoughts?

11 June 2009, 14:42

Same thing with Mahara 1.1.4

Could not execute command: CREATE TABLE grouptype_cron ( plugin VARCHAR(255) NOT NULL, callfunction VARCHAR(255) NOT NULL, minute VARCHAR(25) NOT NULL DEFAULT '*', hour VARCHAR(25) NOT NULL DEFAULT '*', day VARCHAR(25) NOT NULL DEFAULT '*', dayofweek VARCHAR(25) NOT NULL DEFAULT '*', month VARCHAR(25) NOT NULL DEFAULT '*', nextrun DATETIME DEFAULT NULL, CONSTRAINT PRIMARY KEY (plugin, callfunction), CONSTRAINT groucron_plu_fk FOREIGN KEY (plugin) REFERENCES grouptype_installed (name) )TYPE=innodb

Call stack (most recent first):

• execute_sql("CREATE TABLE grouptype_cron (
  plugin VARCHAR(2...", true) at /srv/www/mahara-1.1.4/htdocs/lib/dml.php:1360
• execute_sql_arr(array(size 2), true, true) at /srv/www/mahara-1.1.4/htdocs/lib/ddl.php:599
• create_table(object(XMLDBTable)) at /srv/www/mahara-1.1.4/htdocs/lib/db/upgrade.php:348
• xmldb_core_upgrade("2008040218") at /srv/www/mahara-1.1.4/htdocs/lib/upgrade.php:271
• upgrade_core(object(stdClass)) at /srv/www/mahara-1.1.4/htdocs/admin/upgrade.json.php:71

11 June 2009, 16:35

Found the problem!

Utf8 - our default charset is forced to utf8, the db upgrade seemed to work when we used latin1.  Ugh this is gonna be a pain to move the default charsets, Moodle needs to retain utf8.

 Now I have another problem:

[11-Jun-2009 14:30:52] [WAR] 5c (lib/db/upgrade.php:636) rename(/srv/wwwdata/mahara/artefact/internal/profileicons,/srv/wwwdata/mahara/artefact/file/profileicons) [function.rename]: Directory not empty
 

Is that from a failed upgrade?

11 June 2009, 21:29

Hi.

If your database was latin1, then that was unfortunately a mistake. We didn't pick up that MySQL was allowing people to use latin1 encodings until Mahara 1.1, so new installs from there will warn you but older installs may be using latin1 encodings which isn't good.

Long term, your best option is to move to UTF8 charset. Though you might need to force latin1 for the upgrade, like you say.

As for that warning. I think you can ignore that. Basically, when you ran the upgrade the first time, it probably bailed out  after having done that rename. Mahara doesn't bother moving things back in that instance. We should probably hide the warning as it's irrelevant. All that matters is that the rename was done probably successfully the first time around.

12 June 2009, 0:06

Hi Nigel,

 We are experiencing the same problem with an upgrade from 1.09 to 1.1.x and what we have found is that some tables that get created in the 1.1.x upgrade are created as Type=MyISAM rather than InnoDB as are the others.The problem is that on most servers we can not set the default for the MySql Server to InnoDB and the update script seems not to be specifying Type=InnoDB for these tables.

This looks like causing the errors with the foreign keys.

Will confirm this - but might help some people.

Cheers,

Leo

13 June 2009, 0:45

Hi - that's very interesting indeed. I had a look at the upgrade process, and saw a few places where we're creating tables and not specifying TYPE=innodb.

Here is a patch that fixes that problem in the upgrade process. Are you able to apply it, and see if it fixes your problem?

Anyone else with MySQL upgrade problems to 1.1 should also try this patch if they can (please remember to back up things of course!)

14 June 2009, 20:35

Hi Nigel,

 Just checked the upgrade with the patch and it seems to have fixed the issue (on our test environment at least). 

 Will check the same on the production version as well.

 Thanks for the quick patch !

 Cheers,

Leo

14 June 2009, 22:22

15 June 2009, 12:00

Hi Nigel,

 The patch works great!

 Much Thanks!

15 June 2009, 21:35

Ok, based on the success reports, I have applied the patch, and it will be in Mahara 1.1.5, which should help other people upgrading on MySQL from 1.0.X.

Good sleuthing guys!