Dataクラスでバージョンを操作するときのコンセプトを修正予定に。
さっきお風呂入ってて思ったのですが、お風呂はいる前までは、current_versionも同時に変更できるようにしていたのです。
データの更新については大まかに以下の種類があります。
- 名前やACLなど「属性値」の更新
- 現在バージョンの変更
- データ本体の変更(以下2つの排他)
- バージョンアップを伴う。
- バージョンアップを伴わない。
で、これをマトリックスにしようとすると結構面倒くさくなるのです。特に
- 現在バージョンの変更
- データ本体の変更
がバッティングしたとき。どうしろよというのよ？
実際のところ、現実問題としてこのバッティングは発生しない。というか、開発者ですら途方に暮れるような変更内容なので、そういう操作はできないような画面にしちゃう。
いや、実際、画面としてこんな操作はあり得ない。Wikiも、画像も、添付ファイルも、基本的には更新画面に関して言えば次のような感じ。
- 現在のバージョンのデータ内容を表示する部分
- 属性値を更新する為の入力フォーム
- 新しいデータ本体を入力する為のフォーム。
- 「バージョンアップする？」を選択できるラジオボタンなどのフォーム
ここに、バージョンを変更する為の既存バージョンのリストと、選択の為のラジオボタンを混ぜる事はありうるのか・・・？
ねぇよ。そんなの。
だってユーザー側から見れば、そんなフォーム訳分からない。データ本体の変更してなおかつ、バージョン選択のラジオボタンを弄るとどうなるのか？・・・ユーザーも予測できないだろうし、開発者（今のところ自分一人だけだけど）もどうすりゃいいのか途方に暮れてる。
というわけで、却下。
つまるところ、更新には次の２種類になる。
- 属性（現在バージョンを除く）＋データ本体
- 現在バージョンのみ
前者について言えば、テストするパターンは以下に収まる。
| 属性更新有無 | データ本体(VerUP有) | データ本体(VerUP無し) | パターン |
| ○ | - | - | A |
| - | ○ | - | B |
| - | - | ○ | C |
| ○ | ○ | - | D |
| ○ | - | ○ | E |
| パターン | 属性の"更新日/者" | 属性の"現在バージョン" | バージョン情報 |
| A | 更新 | - | - |
| B | 更新 | カウントアップ | 新規レコード追加 |
| C | 更新 | - | 既存レコード更新 |
| D | 更新 | カウントアップ | 新規レコード追加 |
| E | 更新 | - | 既存レコード更新 |
また、現在バージョンのみの変更の場合も属性のupdated_at/byを更新する。
・・・なんか、結局属性のupdated_at/byは全部で変更しているのだけれど。実はこれはコレで良い。いや、風呂入る前のテストケースでは違っていて、属性だけでは更新してなかったりするのだけれど。
但し、ユーザーが「更新日付順の一覧」を見たとする場合、やっぱり、属性のupdated_at/byも同じじゃないと不自然でしょう。
まぁ、結局属性ファイル自体はどのルートでも更新掛かってしまうことになるので、ロジックも多少簡単になりそう。
決まるモノ決まったので、ラスト、風神録で軽く遊んでから寝るか・・・。( ﾟДﾟ)y─┛~~
