25 February 2009, 20:05

Finally, it's here! This release contains a raft of new features over the 1.0 series of Mahara. The major ones are the ability to copy Views, lots of improvements to Groups, the ability to import content from other systems (such as Moodle 2.0) and user profile pages as Views. Many other smaller improvements and bugfixes have been made.

 This release includes an upgrade path from 1.0. If you wish to upgrade, we encourage you to make a copy of your 0.9 website and test the upgrade on it first, to minimise the effect of any potential unforseen problems.

You can read the release notes, or get downloading (.tar.gz, .tar.bz2, .zip). Enjoy!

25 February 2009, 23:01

Dear Nigel,

I just upload the new version and stop at:

Could not execute command: ALTER TABLE "ma_view_feedback" DROP FOREIGN KEY viewfeed_aut_fk

Call stack (most recent first):

    * execute_sql("ALTER TABLE {view_feedback} DROP FOREIGN KEY viewf...") at /web/arden.aut.ac.nz/htdocs/mahara/lib/db/upgrade.php:665
    * xmldb_core_upgrade("2008040218") at /web/arden.aut.ac.nz/htdocs/mahara/lib/upgrade.php:271
    * upgrade_core(object(stdClass)) at /web/arden.aut.ac.nz/htdocs/mahara/admin/upgrade.json.php:71

My current views still there. But, No one can access the login page. Please help!!!

I was on Mahara1.09

PHP5/MySql4/Linux

Moodle1.9.4

26 February 2009, 0:12

You were on MySQL 4? Are you sure? Mahara doesn't run on MySQL 4.

Thanks for the report, someone else has reported a similar issue so I guess it's something we will have to investigate.

26 February 2009, 4:38

26 February 2009, 18:08

25 February 2009, 23:13

Upload the zip file again. Only copy over the config.php file. (Last time, I copied my theme files). But, shows a new  the error message, 

Could not execute command: ALTER TABLE "ma_group" ADD grouptype CHARACTER VARYING(20)

Call stack (most recent first):

• execute_sql("ALTER TABLE {group} ADD grouptype CHARACTER VARYIN...") at /web/arden.aut.ac.nz/htdocs/mahara/lib/db/upgrade.php:165
• xmldb_core_upgrade("2008040218") at /web/arden.aut.ac.nz/htdocs/mahara/lib/upgrade.php:271
• upgrade_core(object(stdClass)) at /web/arden.aut.ac.nz/htdocs/mahara/admin/upgrade.json.php:71

26 February 2009, 0:18

Ok I think this error has occured because of MySQL fail.

Basically, when you ran the upgrade the first time, there was an error so it stopped. But because MySQL doesn't understand about statements that alter your database structure in transactions, it left your database in a broken state where everything before the error has run. So now when you run the upgrade again, it tries to run things it has already done, and thus complains about those.

The only solution for this is for you to restore your database from the backup you made before attempting the upgrade, and re-running the upgrade. In theory you'll need to patch the upgrade to stop trying to remove that foreign key that was causing issues before re-attempting the upgrade.

If you didn't make a backup before upgrading, you might be in a bit of trouble

PostgreSQL doesn't have this problem, by the way. It understands about changing database structure in transactions, so if a query fails, it undoes all of the changes it made. So you would then just have to fix the upgrade and run it again.

26 February 2009, 4:47

Do you mean I shouldn't use MySql at all? I did upgrade before without any problem. Is this V1.1 doing big change on database?

I might have to setup a fresh site and install Mahara1.1 from start point. Then ask my users to redo their portfolio. (I should backup my database first)

26 February 2009, 5:52

"Do you mean I shouldn't use MySql at all?"

I think Nigel was just pointing out that PostGres would have handled this particular situation better than MySQL. I dont think there is anything "wrong" with using MySQL with Mahara.

Jez

26 February 2009, 6:39

Hi - what I mean is that you will have to restore from the backup you made, and try the upgrade again. If it doesn't work, then we will try and work out a fix to the upgrade for you, then you can restore from your backup and try again.

If you didn't make a backup, you might be in trouble. I can possibly give you some instructions to reverse the part of the upgrade that has happened, if it didn't go too far through.

Upgrading from 1.0 to 1.1 does make big database changes, yes. Which is why it's very important to back up your database before attempting the upgrade, and also why we recommend you try it on a copy of your production site first.

As Jez says, my notes about Postgres were just for information. It would handle the situation better

Let me know if you want to try reversing the upgrade.