データベーススキーマの確認

あなたのMoodleサイトを複数のバージョンに渡ってアップグレードしている場合、データベーステーブル定義 (スキーマ) において、新しく作成される空のMoodleサイトとの差異が生じている可能性があります。これは小さなエラーまたはアップグレードスクリプト内の見落としによって発生します。これらの差異の多くはトラブルを発生させることはありませんが、いくつかは未知または予想外のエラーを発生させる可能性があります。たとえば、フィールドにデフォルト値が追加されたにも関わらず、デフォルト値の存在を前提としてアップグレードスクリプトコードに反映されていない場合、期待どおりに動作しない可能性があります。

アップグレード後の解決方法 (または、アップグレード失敗時の解決方法) は、アップグレードなしで新しく作成されたサイトと実運用サイトに完全に同じコードを使用して比較することです。これを実現する方法は数多くありますが、この記事ではUnixコマンドラインを使用したシンプルな方法を説明します。

アップグレードを完了します。
以下のコマンドを使用して、あなたが直前にアップグレードしたサイトからデータベーススキーマを作成してください:

   mysqldump -d -u root -p myproductiondb >production.schema

Copy the code of your production database to a new (web accessible) location (this is important, it *must* be the same version)
Create a new, empty database and moodledata area for the new site as per the Installation instructions
Edit the config.php file to point at the new database and locations, or delete it and use the install script
Run the install script to generate the (if applicable) config.php file and the database (admin and site values are not important)
Generate the database schema from your new site using the following command:

   mysqldump -d -u root -p mycleandb >clean.schema

Run the following command to detect the differences

   diff -u production.schema clean.schema >db.diff

You can now look at db.diff with your favorite editor to see the differences.

NOTE: The above obviously applies to MySQL databases. Other databases are likely to have a similar function to dump only the schema. For example PostgreSQL has the pg_dump command. The remainder of the discussion still applies.

Interpreting the diff file

Firstly here's a (real) example:

    --
    -- Table structure for table `mdl_backup_config`
       @@ -129,11 +93,11 @@
        DROP TABLE IF EXISTS `mdl_backup_config`;
        CREATE TABLE `mdl_backup_config` (
   -  `id` int(10) unsigned NOT NULL auto_increment,
   +  `id` bigint(10) unsigned NOT NULL auto_increment,
      `name` varchar(255) NOT NULL default ,
      `value` varchar(255) NOT NULL default ,
       PRIMARY KEY  (`id`),
   -  UNIQUE KEY `name` (`name`)
   +  UNIQUE KEY `mdl_backconf_nam_uix` (`name`)
        ) ENGINE=MyISAM AUTO_INCREMENT=15 DEFAULT CHARSET=utf8 COMMENT='To store backup configuration variables';

The file may have lots of blocks of changes. The - lines show lines to be taken out and the + lines the ones to replace them (from the production to the clean). So here, the int has been replaced with a bigint and the key name changed. Both of these, technically, should have been changed at some point by upgrade scripts but have been missed. In this case they are unlikely to affect the operation of Moodle.

Too many changes to track manually?

You can also use database management programs to synchronize old and new Moodle databases.

For example MySQL Workbrench for MySQL databases.

This is very useful, if You have a lot of changes.

If you can work a Unix/Linux command line the Python script Schema Sync provides a quick and simple way to generate all the commands to update your database.

Should I worry?

Changes in field types (as long as they are compatible) and key name changes seem to be the common issues but should not cause problems. Things to look out for would be along the lines of missing fields and changes to default values.

If you are about to upgrade to Moodle 2.0 you should be more concerned. In order for the upgrade to proceed smoothly it is a very good idea to correct these problems.

Documentation

データベーススキーマの確認

目次

Interpreting the diff file

Too many changes to track manually?

Should I worry?

関連情報