ゲーム一覧の料金や台数は時間とともに変わる。そのたびに別の設置として扱うと、故障報告や過去の修正を追いにくくなる。8月には設置の固定IDと時点ごとの値を分離し、一覧全体の置き換え要求を項目別の追加・修正・削除へ変更した。

共同編集と一覧全体の保存

店舗文書は複数の人が編集する。例えば同じ一覧を開いた二人が、それぞれ料金と台数を直すことがある。読み込んだ一覧全体を保存すると、後の保存が先の修正を元に戻しかねない。何を変えたかに加え、どの状態から編集したかもサーバーに伝える必要がある。

改修前のゲーム入力画面。フォームの変更を項目ごとに識別し、以前の値と比較できる必要があった。 英語の原キャプチャ。

保存のたびに項目IDを作り直す方法にも問題がある。料金や台数の変更でも同じ設置を指すはずが、関連する報告や履歴を結びにくくなる。構造化した変更履歴を提供するには、要求でも継続する項目と編集の基準を特定できなければならない。

flowchart TD
    accTitle: 一覧全体の置き換えで失いやすい二つの情報
    accDescr: 一覧全体の再保存には項目の同一性と読んだ基準状態が必要で、欠けると参照や同時編集を検証しにくい。
    A[一覧を読んで編集] --> B[一覧全体の置き換え要求]
    B --> C[同じ項目かを識別]
    B --> D[読んだ基準状態を確認]

設置IDと時点ごとの修正版

arcade_game_idは店舗に登録された設置項目を継続して示す。バージョン、台数、料金などの値はrevisionに保存する。カタログIDが製品の種類と互換性を示すのに対し、このIDは特定店舗の設置を識別する。

故障報告のgame_idも設置IDを参照する。編集のたびにゲーム全体の情報を報告へコピーし直さず、同じ対象を追える構造である。当時の値はrevisionから確認し、報告は継続する設置につなぐ。

flowchart LR
    accTitle: ゲームIDと時点ごとの値の分離
    accDescr: 現在のbatch内のrevisionは維持される項目IDを参照し、過去のrevisionや故障報告も同じIDにつながる。
    A[arcade.game_v2] --> B[現在のbatch]
    B --> R[現在のrevision]
    R --> I[arcade_game_id]
    O[過去のrevision] --> I
    F[故障報告] --> I

一覧全体の時点ごとの構成はbatchとして残す。arcade.game_v2が現在のbatchを指し、過去のbatchとrevisionも保持する。要求にはadd・modify・removeを含め、どの項目が追加・変更・削除されたか分かるようにした。

差分の保存と競合処理

編集開始時のbatch IDをbase_state_idとして送る。サーバーはトランザクション内で権限と現在のbatchを調べ、一致した場合に差分を適用する。新しいbatchとrevision、現在の参照、変更履歴をまとめて保存し、一部だけ変わる状態を防ぐ。

sequenceDiagram
    accTitle: 同じAから始まった二つの編集
    accDescr: 最初の編集者がB・ポインター・履歴を保存すると、Aを基準とする2人目の編集には409を返す。
    participant E1 as 編集者1
    participant S as サーバー
    participant E2 as 編集者2
    S-->>E1: 現在のbatch A
    S-->>E2: 現在のbatch A
    E1->>S: 基準Aと差分
    Note over S: B・ポインター・履歴を同時保存
    S-->>E1: 保存したB
    E2->>S: 基準Aと差分
    S-->>E2: 409 Conflict

例えば二人がAから始め、最初の保存でBになった場合、Aを基準とする次の要求には409 Conflictを返す。画面の入力内容は保持する。基準IDだけを最新に差し替えたり自動統合したりせず、利用者が最新構成と自分の変更を確認できるようにした。

過去構成の復元と保存量

台数が2台から3台になっても設置IDは同じなので、修正履歴と故障報告を追い続けられる。復元では編集権限と履歴の所属店舗を確認し、現在の参照を過去のbatchへ移す。個々の値を組み立て直す代わりに保存済みの構成を選ぶ方法である。

flowchart LR
    accTitle: 過去の状態を保つ復元
    accDescr: 現在のポインターを過去のbatchへ移し、新しい復元履歴に前後を記録する。既存のbatchと履歴は残る。
    P[現在のポインター] -->|復元後| A[過去のbatch A]
    P -.->|復元前| B[最近のbatch B]
    L[新しい復元履歴] -->|変更前| B
    L -->|変更後| A

BからAへ戻してもBや既存のA→B履歴を削除せず、B→Aという復元履歴を追加する。現在値に至った経緯を確認できる一方、小さな編集でも構成全体のrevisionを保存する容量が必要になる。別の項目を編集していてもbatchが違えば競合する。自動統合より、古い状態で無意識に上書きしないことを優先した。

関連する記事と資料：構造化した編集履歴 · 故障報告 · Musecatの開発記録