Turns out I got the table_column call wrong also. Needs to, like with everything else in xmldb, fully respecify the column. Now the view migration works in MySQL

XMLDB and MySQL conspired to make this a horrible process.

Removed a couple of unneeded debugging lines from the view migration. Made sure to make the block column of the view_artefact table not null after the upgrade, and clear out all the null rows

 * Up the memory limit to 64M. The 16M limit was hit when migrating a 600 view Mahara, so I don't imagine 64M will be hit in the wild
 * Move the installation of the blockinstancecommit event to before the view migration. This is so that such events can be fired safely by blockinstances that are being committed
 * Install _all_ of the blocktypes when upgrading

Namely, when a block doesn't migrate properly.

Also reduced the size of resized images in views somewhat to work better on smaller screens.

The template itself is reasonably simple, the problems lie around the translation of certain template blocks to blocktypes - but these problems affect all templates.

Anyway, it now migrates reasonably well. The labels are only output if there's artefacts associated with them.

Also changed a couple of columns in view_artefact to be nullable while the migration is running. Tried this with XMLDB, it ate my face.

Added an upgrade path to move the images stored on the filesysetm into a new directory structure, and set config variables regarding image height and width.

Also removed a newline at the end of the file that was triggering header output.

There are lots of TODOs and none of the blocks get created.
It just moves stuff around according to the templates.

NOT TESTED.

removed all upgrades previous to the last minupgradefrom... this means we can get rid of the previous view template upgrades

First pass at a mysql upgrade for the usability work. Has to pull some shennigans with the paperwork^Wforeign keys

Implemented postgres upgrade to rename the community stuff to group. Will do the MySQL one at the end

Now, table names (and other identifiers that could be confused with SQL kewords), should be put into SQL like this:

SELECT * FROM {artefact}

The braces are matched and expanded by DML now to include the prefix and be properly quoted, which means that tables like 'view' and 'group' don't need renaming (and nor should they, there's little reason why we should rename tables to get around such constraints).

This has removed a whole bunch of $prefix = ... and get_config('dbprefix') stuff, which makes things a little simpler yet again.

Upgrade to remove group tables from Mahara. They'll be back, as renamed community tables, but for now, farewell! *plays taps*

More database consistency fixes. Made sure many NOT NULL columns didn't unnecessariliy have a DEFAULT '' on them. Made sure the MySQL default isn't to make them DEFAULT '' either

REALLY corrected the name of the index PROPERLY. Geez I'm having a good day. You there, reading the commit message, how are you?

Revert "Upgrade to remove group tables from Mahara. They'll be back, as renamed community tables, but for now, farewell! *plays taps*"

Back they come... stupid wrong branch...

This reverts commit 035ebd5d.

Upgrade to remove group tables from Mahara. They'll be back, as renamed community tables, but for now, farewell! *plays taps*

Fix issue found when attempting to upgrade a dupe of myportfolio.ac.nz - lang setting might already be fixed in the database, causing a foreign key violation