複数のモデルで同じDBテーブルを使う

1. このページで伝える機能

テーブル共有を使うと、用途の異なる複数のモデルから、同じDBテーブルのレコードを利用できます。例えば、詳しい内容を登録・更新する不具合報告モデルと、必要な項目だけを参照するモデルを分けられます。

共有先モデルには、テーブルを持つ共有元モデルを指定します。共有先専用のテーブルへデータをコピーする構成ではなく、同じ保存先を使います。PC向け・モバイル向けなど、用途別のモデルを設計するときにも利用できます。

2. Wagby11で実現できること

2.1 用途を分けて同じレコードを利用する

次の図では、不具合報告の共有元モデルでID・件名・詳細を扱い、共有先モデルではID・件名だけを参照します。共有元で件名を変更すると、共有先も同じテーブルの更新後の値を取得します。表示済みの画面を自動更新する仕組みではありません。

この構成では、モデルごとに扱う項目や権限、画面の設定を分けます。共有先の作成だけで、端末に応じたモデルの自動切り替えやメニューの追加が行われるわけではありません。利用者への入口も別に指定します。

2.2 共有元と共有先の定義をそろえる

共有先のtable_shared_withへ、共有元の英語識別名を指定します。共有元のすべての項目を共有先へ並べる必要はなく、用途に必要な永続項目を選べます。ただし、同じ保存先を使うため、次の条件を満たす必要があります。

• 共有先の主キー列は共有元と一致させます。
• 共有先の永続項目は、同じDB物理列名・属性型で共有元に存在するものを使います。
• 共有先にtable_shared_withとrdbnameを同時に指定しません。保存先は共有元から決まります。
• 共有元には、実在するテーブル所有モデルを指定します。自分自身や別の共有先を指定すること、共有を連鎖・循環させることはできません。

AIには、主キーや型に加えて、文字列の長さ・数値の桁数・制約なども既存の保存先と整合するか確認させます。共有先だけへ永続項目を追加しても、その列を新設する設定にはなりません。

2.3 更新方法と競合への対応を決める

まずは、図のように共有元で更新し、共有先は参照のみとする構成にすると、更新する役割を分けられます。共有先の操作権限に参照だけを許可し、登録・更新・削除は許可しません。テーブル共有の指定だけで読み取り専用にはならないため、認証と認可も合わせて設定します。

両方のモデルから同じレコードを更新する場合は、更新の競合に対応する必要があります。同じレコードを両方から同時に更新しない運用にするか、両モデルで同じversion列を使い、楽観ロックで競合を検出できるようにします。

楽観ロックは、読み取った後に他の利用者が更新していた場合、その競合を検出する仕組みです。共有元・共有先で項目が同じというだけでは、競合への対応を確認したことにはなりません。

2.4 DB構造とデータ移送は共有元で管理する

共有先モデルについて、新しいテーブル・索引・外部キー・コメントのDDLは生成しません。DB構造の管理は共有元で行います。共有先の項目を変える際も、共有元と実際の列との対応を確認します。

エクスポート・インポートは共有元モデルを使います。共有先は、同じテーブルのデータを二重に移送しないよう、データ移送の対象外になります。共有先を別のバックアップ用モデルとして使うものではありません。

3. AIへの指示例

最小限の指示例

不具合報告と同じデータを使い、IDと件名だけを参照できる概要参照用モデルを追加してください。データはコピーせず、同じDBテーブルを共有してください。

AIは共有元モデル、共有先の英語識別名、必要な主キーと項目、利用者の権限、メニューなどを既存の定義から類推して補います。どの利用者に何を許可するか、共有先で扱う項目は具体的に伝えます。この短い指示だけで、次の詳細例と同じモデル名や権限になるとは限りません。

より詳細な指示例

Wagby11のguideと必要なreferenceを確認し、既存の不具合報告BugReportに概要参照用モデルを追加してください。
・共有先の表示名は「不具合報告（概要参照）」、英語識別名はBugReportSummaryとしてください。
・BugReportSummaryのtable_shared_withにBugReportを指定し、同じDBテーブルのレコードを使ってください。
・共有先はreportIdとsubjectを持つ構成とし、共有元の主キー列・物理列名・型・長さと整合させてください。
・共有先へ独自のrdbnameを指定せず、テーブルやデータを複製しないでください。
・G_STANDARD（標準ユーザ）には共有先の参照だけを許可し、登録・更新・削除は許可しないでください。
・概要を確認する検索一覧・詳細画面とメニューを用意してください。共有元の既存の画面・権限・データは保持してください。
・共有元が未定義、または指定項目が存在しない場合は、新しく作る前に確認事項を示してください。
設計情報の検証・コード生成・必要なビルド後、REST APIとWeb UIを再起動してください。
共有元と共有先で同じID・件名を参照できること、共有元の更新後に共有先で値を再取得できること、共有先から更新・削除できないことを確認してください。
共有先のDDLとデータ移送が重複して生成されないことを確認し、変更内容と確認結果を説明してください。

両方のモデルから更新したい場合は、その要件を別に伝え、同じversion列による競合検出と同時更新時の動作確認も依頼します。

4. 編集されるAppSchemaの例

以下は図の構成に対応する定義の抜粋です。利用者は構文を覚えなくても、共有元、共有先で扱う項目、許可する操作をAIに伝えられます。既存のモデルに合わせて項目・権限・画面・メニューを整えます。

共有元：テーブルを持つモデル

designer/repository/appschema/BugReport.yamlの例です。

entity:
  name: 不具合報告
  name_en: BugReport
  rdbname: bug_report
  type: T
  attributes:
    - { name: ID, name_en: reportId, type: autoid, pk: true }
    - { name: 件名, name_en: subject, type: string, length: 100 }
    - { name: 詳細, name_en: details, type: string, length: 1000 }
# 既存の権限・画面などの定義は保持

共有先：必要な項目を参照するモデル

designer/repository/appschema/BugReportSummary.yamlの例です。table_shared_withに指定するのは、DBテーブル名のbug_reportではなく、共有元の英語識別名BugReportです。

entity:
  name: 不具合報告（概要参照）
  name_en: BugReportSummary
  table_shared_with: BugReport
  type: T
  attributes:
    - { name: ID, name_en: reportId, type: autoid, pk: true }
    - { name: 件名, name_en: subject, type: string, length: 100 }
permissions:
  - role: G_STANDARD
    crud: [R]
# 検索・一覧、画面、メニューは別途設定

例ではmigration_idなどを省略しています。共有先は別モデルなので、共有元の固定IDを複製して流用しません。詳しくはモデル・項目の固定IDを参照してください。両モデルから更新する構成のversion設定は、この参照専用の例には含めていません。

5. 参考資料

guide：エンティティ間の関係

designer/docs/appschema/html/guide/03-model/03-relations.html

reference：entity

designer/docs/appschema/html/reference/06-entity.html

reference：permissions（CRUD権限定義）

designer/docs/appschema/html/reference/07-permissions.html