モデルの項目を定義する

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

モデルには、管理したい情報を項目として定義します。商品なら商品コード・商品名・単価です。項目の名前、扱う値の型、長さや桁数、必須条件を決めると、標準画面の入力欄や保存時のチェックに反映されます。

このページは項目をどう組み立てるかを説明します。型ごとの詳しい機能は項目の型と入力方法で扱います。

表示名・英語識別名・DB物理名の使い分けは、モデルと項目の名前を決めるで説明します。

2. Wagby11で実現できること

2.1 指定できる項目の型

まずは「どんな値を扱いたいか」で型を選びます。型の指定はAIに任せられますが、電話番号の先頭の0や、金額の小数桁など、残したい情報を伝えてください。

型ごとの入力画面や設定例は項目の型と入力方法、他のモデルを選ぶ設定はモデル間の関係と参照で説明します。

2.2 項目に合った入力欄を用意する

2.3 入力する項目と、検索・一覧で使う項目を決める

商品コードと商品名は検索条件にも使い、単価は一覧の表示項目に含めています。項目を定義することと、検索条件や一覧へ配置することは分けて指定できます。この例では独自レイアウトを追加せず、既定レイアウトを使っています。

2.4 既存項目の型や識別子を変更するとき

すでに使っている項目を変更すると、入力欄以外にも影響します。例えば商品コードを文字列から整数へ変えると、「P001」は数値にできず、「001」の先頭の0も残せません。小数の単価を整数へ変える場合は、小数部分をどう扱うかを決める必要があります。

nameは画面に見せる名前、name_enは設計情報の中で項目を指す識別子です。「商品名」を「商品名称」と表示し直すことと、productNameを別の識別子へ変えることでは影響が違います。識別子は検索・一覧・計算式・他モデルの参照やAPIからも使われるため、それらの修正も必要になる場合があります。

既存の項目を改名するときは、同じ項目を追跡する固定識別子migration_idを保持します。IDの目的と手動編集時の注意点はモデル・項目の固定IDで説明します。また、設計情報を変更して生成するだけでは、既存DBの値を安全に変換できるとは限りません。変更前のデータを残す方法と、DBへ変更を反映する追加移行の内容を確認してから進めます。

再生成と、既存DBへの反映を分けて確認する

AppSchemaのtypeを変更してJavaコードを再生成しても、それだけで既存DBの列型が直接書き換わるわけではありません。アプリケーションが扱う型と、保存先の列型を一致させるには、DBへ変更を反映する移行処理が必要です。

Wagby11は一部の安全な型拡張に対応する変更SQLを自動生成します。すべての型変更が対象ではなく、日付から文字列への変更など、対象外の変更ではDB定義の生成を停止します。自動生成されたSQLがある場合も、その内容と既存データへの影響を確認します。

データを残すDBと、作り直せる開発DBを分ける

追加マイグレーションは、過去のSQLを残したまま、その後に適用する変更SQLを追加する方法です。自動生成の対象外では、利用するDBとデータの内容に合う変換SQLをAIに検討してもらいます。バックアップを用意し、実データを使った検証環境で変換結果を確認してから、対象DBへ適用します。

開発DBの再構築は、既存データを引き継いで型変換する方法とは異なります。DBだけを作り直しても古いDDLが残っていると、変更前の列型が再作成されます。DBとDDLを一緒に扱う必要があるため、AIには対象の接続先・保存先と再構築の計画を先に確認させます。

DB列型や履歴の不一致で起動できない場合の確認手順は、DB構造とマイグレーションの不一致を調べるを参照してください。

3. AIへの指示例

最小限の指示例

商品に商品コード・商品名・単価の項目を用意してください。

各項目の型、文字数・桁数、必須条件や画面への配置はAIが類推して補います。入力のルールや検索・一覧の項目を決めている場合は、次のように具体的に伝えます。

より詳細な指示例

商品モデルの項目を確認し、次の内容にしてください。
商品コードは文字列・最大30文字で、登録・更新時とも必須にし、値の重複も禁止してください。
商品名は文字列・最大100文字で、登録・更新時とも必須にしてください。
単価は任意入力の固定小数点数で、全体12桁、小数部2桁にしてください。
商品コードと商品名を検索条件にし、一覧には商品ID・商品コード・商品名・単価をこの順に表示してください。
既存の主キー、監査項目、権限、データは保持してください。
変更後は検証・再生成を行い、入力欄と一覧への反映を確認してください。

既存項目の型変更を検討する指示

最小限の指示例

商品コードを文字列から整数へ変えたいので、既存データへの影響と必要なDB移行を調べてください。まだ変更は実行しないでください。

AIは対象項目、現在のDB、関連する定義を調べ、必要な変換や移行方法を検討します。先頭の0を残したいか、既存データをすべて保持する必要があるかなど、業務上の条件は具体的に伝えます。この短い指示だけで、次の詳細例と同じ調査範囲になるとは限りません。

より詳細な指示例

商品コードを文字列から整数へ変える案を検討しています。まだ変更は実行しないでください。
保存済みデータに「P001」や「001」のような値がないか調べ、変換できない値と先頭の0が失われる影響を説明してください。
検索・一覧・計算式・他モデルの参照・APIへの影響と、既存データを保持する移行方法を示してください。
商品名の表示だけを「商品名称」へ変える場合と、識別子productNameも変える場合の修正範囲を分けて説明してください。
同じ項目のmigration_idを保持し、必要な修正ファイル、追加する移行SQL、確認項目を提案してください。
データを保持するDBでは、適用済みSQLを変更せず、バックアップと検証環境での移行確認を含む計画を示してください。
開発DBの再構築を提案する場合は、作り直せるデータかを確認し、DBと生成済みDDLを組で退避する計画を別に示してください。
自動生成できる変更と、追加の変換SQLが必要な変更を分けて説明してください。

4. 編集されるAppSchemaの例

designer/repository/appschema/Product.yaml内の業務項目の抜粋です。nameが表示名、name_enが内部で使う識別子です。

# entity.attributes 内の業務項目
- name: 商品コード
  name_en: productCode
  type: string
  length: 30
  not_null: true
  unique: uq_product_code
  validation:
    presence: { create: error, update: error }
- name: 商品名
  name_en: productName
  type: string
  length: 100
  validation:
    presence: { create: error, update: error }
- name: 単価
  name_en: unitPrice
  type: decimal
  precision: 12
  scale: 2

検索条件と一覧は次の定義です。

functions:
  - description: 商品検索
    filter:
      - name_en: productCode
      - name_en: productName
    list:
      - name_en: productId
      - name_en: productCode
      - name_en: productName
      - name_en: unitPrice

全体例は商品モデルのAppSchema例を参照してください。

5. 参考資料

guide：エンティティ属性タイプ

designer/docs/appschema/html/guide/03-model/02-fields.html

guide：登録・更新の必須チェック

designer/docs/appschema/html/guide/04-validation/01-required.html

guide：トラブルシューティング

designer/docs/appschema/html/guide/appendix/04-troubleshooting.html

reference：entity

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

reference：functions

designer/docs/appschema/html/reference/09-functions.html