Actions

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

From Mahara Wiki

< 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」カラムを使用してください。

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

コアアップグレード: すべてのページ読み込み (!) において、Maharaはコードのバージョン番号 (htdocs/lib/version.phpに保存されます) をデータベースのバージョン番号 (設定テーブルの 「version」行に保存されます) と比較します。もしデータベースのバージョンがコードのバージョンより小さい場合、アップグレードが命令された上でhtdocs/lib/db/upgrade.php内のコードが実行されます。それぞれのアップグレードは現在のデータベースバージョン ($oldversion) より大きなアップグレードのみ実行されるよう「if ($oldversion < ...) { ... }」ブロックの中に置かれます。

アップグレード中にエラーが発生した場合、通常はSQLExceptionにスローされて画面に不快なエラーメッセージが表示されたままアップグレードが停止します。アップグレードはトランケーションに包まれているため、Postgres DBではアップグレードに失敗した場合、最初のアップグレード前の状態にロールバックされます。dataroot内のファイル更新中、またはMySQLデータベースの更新中にアップグレードに失敗した場合、一貫性のない不完全なアップグレード状態のデータが残る可能性があります。

プラグインのアップグレードはコアのアップグレードと同じように機能します。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.通常、プラグインはコアがアップグレードされるまではアップグレードされませんが、コアのアップグレード時にプラグインアップグレードを手動でトリガされた場合、この動作が上書きされる場合があります。

一般的にアップグレードコードはMaharaの他の場所で定義された関数ではなく、dmlおよびxmldbの低レベル関数のみを使用すべきです。lib/upgrade.phpにインストール関数を書いてアップグレードスクリプトで同じ関数を使用したくなりますが、私たちはそれは避けるべきだと理解できました。アップグレードスクリプトのコードはアップグレードが書かれた時点でのDBスキーマを使用するよう、かなり「凍結」されているはずです。Maharaライブラリが書き換えられるため、例えば常に存在していたわけではないデータベースカラムを参照できます。その場合、まだ実行されていないアップグレードまではデータベースカラムは追加されないため、書き換えられた関数を呼び出す初期のアップグレードは失敗します。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.