テーブル操作に関する注意点まとめ

最終更新日: 2020年3月14日
R8 | R9

この説明が必要な場合

次のような利用を行う場合に、本文書の内容を参考にしてください。

  • 既存のテーブルを再利用する。（別のシステムからもこのテーブルを利用している。）
  • 運用中に(Wagbyを経由せずに)直接、テーブルのデータの変更(登録/更新/削除)を行う。
  • 別々のモデルで、同じ物理テーブルを共有する。（メインモデルとサブモデルの関係であれば、ここに記載した注意点はすべて考慮されています。メインモデルとサブモデル関係を使わない場合、本文書の注意点に配慮してください。）

ロック

Wagbyでデータを更新する場合、常に更新対象データは「ロック」されます。これによって同じデータの更新によるデータ破壊を防ぎます。

ロック方式は「悲観ロック」と「楽観ロック」の二種類を選択できます。標準は「悲観ロック」です。詳細は"ロック方式"をお読みください。

ロックはWagby内部で制御されています。そのため Wagby の外から直接、テーブルを操作された場合、Wagbyのロック機構は働きません。

ロックを考慮しないでよい場合

対象テーブルが読み込み専用であれば、ロックについて考慮する必要はありません。対象テーブルをWagbyからも更新し、かつ別システムからも更新される可能性がある場合、更新の競合を避けるため、ロックを考慮する必要があります。

楽観ロックが適用できる場合

対象テーブルが楽観ロックに対応しており、かつ「バージョン管理用カラム」をもっている場合は、Wagbyの楽観ロックを利用できます。具体的には、テーブル内に用意された「バージョン管理用カラム」を Wagby および他のシステムで共通に利用するということです。

悲観ロック情報を共有する場合

楽観ロックが使えない場合、Wagbyの悲観ロックテーブルを既存システムと共用することを検討してください。具体的には悲観ロックの情報をデータベースのテーブルとして表し、これを他システムから参照するようにします。

ロックキー

別々のモデルで同じ物理テーブルを共有する場合、ロックキーを同一にするとよいでしょう。 詳細は"ロックキーのカスタマイズ"をお読みください。

キャッシュ

Wagby はデータベースへ発行する SQL を可能な限り削減するようになっています。そのため、一度読み込んだデータをメモリ内に保持し、再利用します。これを「キャッシュ」と呼びます。

そのため Wagby の外から直接、テーブルを操作された場合、Wagbyの保持するキャッシュと実際のデータの整合性がとれなくなります。

そこでモデルのキャッシュを無効にする方法が提供されています。 しかしキャッシュを無効にするとパフォーマンスに影響があります。この問題に対する、いくつかの代案を示します。

定期的にWagbyのキャッシュ情報を消去する

更新頻度が少ない場合、キャッシュは使うが、ジョブを使ってキャッシュ情報を定期的に消去する方法があります。

外部からWagbyのキャッシュ情報を消去する

REST API を使って、Wagbyが保持する（モデルの）キャッシュ情報をクリアすることができます。外部から直接データベースを更新した場合にこの API を呼び出すという方法があります。

マテリアライズドビューを使う

Wagbyのキャッシュは無効としつつ、データベースが提供する「マテリアライズドビュー」を使う方法もあります。[Wikipedia...]

マテリアライズドビューはデータベース側でキャッシュされており、かつ、元のテーブルが変更されるたびにキャッシュも更新されます。そのため最新のデータを取得できます。マテリアライズドビューが使えるデータベースであれば、こちらの利用も検討してください。

データベースによっては「リフレッシュ」処理が必要な場合もあります。お使いのデータベースの仕様をご確認ください。