Actions

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

From Mahara Wiki

< Mahara日本語ドキュメント‎ | 開発者エリア
(done.)
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
作成中です - [[User:Mits|mits]] ([[User talk:Mits|talk]])
* 各プラグインの''type''では{$plugintype}_config、{$plugintype}_cron、{$plugintype}_installed、{$plugintype}_event_subscriptionを取得します。
* 各プラグインの''type''では{$plugintype}_config、{$plugintype}_cron、{$plugintype}_installed、{$plugintype}_event_subscriptionを取得します。
* 個々のプラグインでインストールされるテーブルには$plugintype_$pluginname_を先頭に付加する必要があります (例: ブログ投稿の場合「artefact_blog_post」となります)。
* 個々のプラグインでインストールされるテーブルには$plugintype_$pluginname_を先頭に付加する必要があります (例: ブログ投稿の場合「artefact_blog_post」となります)。
* 標準タイムスタンプフィールドはctime、mtime、atimeと呼ぶ必要があります (creation, modification, access)。
* 標準タイムスタンプフィールドはctime、mtime、atimeと呼ぶ必要があります (creation, modification, access)。
* データベースからデータを取得する場合、<span style="white-space: nowrap">db_format_tsfield</span>関数でタイムスタンプをUNIXタイムスタンプにフォーマットするのが最良の方法です。
* データベースからデータを取得する場合、<span style="white-space: nowrap">db_format_tsfield</span>関数でタイムスタンプをUNIXタイムスタンプにフォーマットするのが最良の方法です。
* 一意名および表示名を持つ場合、フィールドはnameおよびdisplaynameと呼ばれます。
* フィールドが一意名および表示名を持つ場合、nameおよびdisplaynameと呼ばれます。
*変数名のようなデータベースフィールドにはアンダースコア (_) を使用しないでください。
*変数名のようなデータベースフィールドにはアンダースコア (_) を使用しないでください。
* すべての新しいテーブルには主キーとして自動インクリメントの整数「id」フィールドを持つ必要があります (例 [http://en.wikipedia.org/wiki/Surrogate_key サロゲートキー (代理キー)])。
* すべての新しいテーブルには主キーとして自動インクリメントの整数「id」フィールドを持つ必要があります (例 [http://en.wikipedia.org/wiki/Surrogate_key サロゲートキー (代理キー)])。
Line 17: Line 15:
アップグレード中にエラーが発生した場合、通常はSQLExceptionにスローされて画面に不快なエラーメッセージが表示されたままアップグレードが停止します。アップグレードはトランケーションに包まれているため、Postgres DBではアップグレードに失敗した場合、最初のアップグレード前の状態にロールバックされます。dataroot内のファイル更新中、またはMySQLデータベースの更新中にアップグレードに失敗した場合、一貫性のない不完全なアップグレード状態のデータが残る可能性があります。
アップグレード中にエラーが発生した場合、通常は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.通常、プラグインはコアがアップグレードされるまでアップグレードされませんが、コアのアップグレードがプラグインのアップグレードを手動でトリガした場合、この動作が上書きされる場合があります。
プラグインのアップグレードはコアのアップグレードと同じように機能します。通常、プラグインはコアがアップグレードされるまではアップグレードされませんが、コアのアップグレード時にプラグインアップグレードを手動でトリガされた場合、この動作が上書きされる場合があります。


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


[[Category:開発者エリア]]
[[Category:開発者エリア]]

Latest revision as of 07:32, 22 October 2023

  • 各プラグインの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データベースの更新中にアップグレードに失敗した場合、一貫性のない不完全なアップグレード状態のデータが残る可能性があります。

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

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