Mahara日本語ドキュメント/開発者エリア/データベース規約

作成中です - mits (talk)

• 各プラグインのtypeでは{$plugintype}_config、{$plugintype}_cron、{$plugintype}_installed、{$plugintype}_event_subscriptionを取得します。
• 個々のプラグインでインストールされるテーブルには$plugintype_$pluginname_を先頭に付加する必要があります (例: ブログ投稿の場合「artefact_blog_post」となります)。
• 標準タイムスタンプフィールドはctime、mtime、atimeと呼ぶ必要があります (creation, modification, access)。
• データベースからデータを取得する場合、db_format_tsfield関数でタイムスタンプをUNIXタイムスタンプにフォーマットするのが最良の方法です。
• 一意名および表示名を持つ場合、フィールドはnameおよびdisplaynameと呼ばれます。
• 変数名のようなデータベースフィールドにはアンダースコア (_) を使用しないでください。
• すべての新しいテーブルには主キーとして自動インクリメントの整数「id」フィールドを持つ必要があります (例 サロゲートキー (代理キー))。
  • 以前のMaharaではこの慣習に従っていなかったため、多くの古いテーブルには「id」が存在しません。
  • 他のテーブルの外部キーカラムとして「id」カラムを使用してください。

データベースアップグレード

Core upgrades: On every page load (!), Mahara compares the version number of the code (stored in htdocs/lib/version.php) against the version number in the database (stored in the config table in the 'version' row). コアアップグレード: すべてのページ読み込み (!) において、Maharaはコードのバージョン番号 (htdocs/lib/version.phpに保存されます) をデータベースのバージョン番号 (設定テーブルの 「version」行に保存されます) と比較します。 If the db version is less than the code version, an upgrade is triggered, and the code in htdocs/lib/db/upgrade.php is run.  Each upgrade sits inside a 'if ($oldversion < ...) { ... }' block, so that only upgrades greater than the current db version ($oldversion) are run.

Errors in an upgrade will usually cause an SQLException to be thrown, and the upgrade will stop with a nasty error message on the screen.  The upgrade is wrapped in a transcation, so with a Postgres db, an upgrade failure should rollback to the state before the first upgrade.  Upgrades which fail while making changes to files in dataroot or changes to a MySQL db can leave your data in an inconsistent half-upgraded state.

Plugin upgrades work in a similar way to core upgrades.  Plugins are usually not upgraded until after the core is upgraded, but this behaviour is sometimes overridden when a core upgrade manually triggers a plugin upgrade.

In general, upgrade code should only use low-level functions from dml and xmldb rather than functions defined elsewhere in Mahara.  It's tempting to write an installation function in lib/upgrade.php and then use the same function in the upgrade script, but we've found that it should be avoided.  Code in the upgrade script should be pretty-much 'frozen' so that it uses the db schema as it was when the upgrade was written.  Mahara library functions get rewritten, and can refer, for example, to database columns that haven't always existed -- then an early upgrade that calls a rewritten function will fail because the db column is not added until some later yet-to-be-executed upgrade.