駄目だ、今日はDataのテストケース終わらない。

一応何点か覚え書きを。

名前は、バージョン管理はしない。（最初バージョン情報に含ませてしまっていた）
何でかというと、名前検索の場合がやや複雑に過ぎる気がするし、そもそも名前を変更した場合バージョンはどうなるのだ？
名前は属性として一括した方が簡潔だと思う。それで困る人が出るとは思えないし。
あと、それに伴い、属性値の変更日付を持つ。数時間前までは持ってなかった。バージョン情報の方にあるから良いと思っていたのだけれど・・・。でも、現実問題として「データはそのまま（バージョンは不動）で、属性値(ACLとか名前とか)だけ変えたい」という場合が多いはず。となると、まぁ、持っていてまっとうだろうと思う。あぁ、あと、だれに変更されたのか、もか。

あとは・・・チェックサムはMD5とSHA1の二種類を提供することにする。やっぱり。で、該当する物理ファイル(oid.vid.dat)が存在しない場合、空文字列とする。

あと、分かりづらくなったけどDataクラスの段階での「名前」は抽象的な扱い。例えばWiki系のモジュールであれば「ページ名」として扱われ、imageやfile系では純粋にアップロードファイル名(**.xlsとか**.jpgとか)として扱われるだろう。多分。ひょっとしたらファイル名はDataTypeの拡張属性になり、こちらは日本語などで自由に表記できる名前になるかもしれないが。

もう一点。属性の更新と、本体データのバージョンアップは特にメソッドは分けない。Daoのレベルでは、更新データ中にフィールドが設定されているモノについて更新することにしておく。もし本体データが入ってくれば、そのとき本体データをバージョンアップする。
また、本体データのバージョンアップの時、「バージョンカウンタをアップ」するかしないか選べる。バージョンを変えずに、中身だけ差し替えたい場合などに使用する。というか殆どの場合そちらだろう。
これを応用すれば、current_versionエントリだけを設定した更新データを渡すことで、カレントバージョンを切り替える動作も簡単に実現できるだろう。

うにゃ。今日は朝の9時からアパートの用事があった為、あんまり寝てないので眠いのにゃ。おおよそ固まったし、これ以上迷ったら後回しにすることにして、続きと実装は明日にするにょだ。

CategoryのDAO、とりあえず実装終了。

速い。
そりゃそうだ。TestCaseも、実際のクラスファイルも、AclやGroupのコピペ合成だし。

これでバージョン管理を伴わない、いわばYakiBikiでの「システムオブジェクト」についてはdaoを作り終わった。いよいよ本丸の、YakiBikiの「データオブジェクト」に入る。

が、その前に。
Userで、find_by_idで複数のIDを配列でとれるように拡張する。結構使いそうなので、そりゃまぁ究極的にはCache_Liteを使えばお仕舞いなのだろうけど・・・。find_allで取ってきたIDから、対象のUserIDだけをフィルタリングするようなループコードを随所に埋めるのはスマートじゃない。迷うまでもなく、あきらかに有効なショートカットだろう。実装。

Dataオブジェクトのテストケースがまとまらないっっ・・・！！

うううぅぅ・・・まとまらないよぅ。何がまとまらないかって、閲覧時の処理をどうするかがまとまらない。
少なくとも次のフィールドは、ソートあるいはフィルタ対象になる。
owner, acl, thread, category, modified_at, created_at, name
このうち、acl/thread/categoryについては

acl_id1,id|id|id|...
acl_id2,id|id|id|...
...

みたいな形式のIDXファイルを用意して手動で引ける、範疇だ。レコード数が。基点となるACL/THREAD/CATEGORY自体の数が数万のオーダーには達しない。良くて数百。THREADは数千まで行くかな？でも、力業のリニア検索でどうにかできなくはないレベル。
問題は残りの、owner/modified_at/created_at/nameで。
まあ、nameは

name,id(|id...)
name, ...
...

形式のファイルにして、さすがにリニアは面倒くさいので、二分探索でサーチできる。
created_atについても、これは基本的にはレコードのappendしか発生しない。deleteはあるが、updateは発生しない。ので、これもnameと同様の形式で二分探索できる。っつーか、時刻系はinsertの方が良いなぁ。
ownerが面倒くさい。

owner_id,id|id|id|...
...

形式にすると、"id|..."以降が数百、数千のオーダーになる。explode()もさすがにきついだろう。
逃げ道としては、file()でさっくり読み込めるようにowner_idをファイル名に埋め込み、中身はidをEOLでjoinしただけにするのがベターか。

一番厄介なのがmodified_at。これ、どうするよ。これ、1:1じゃないんだもの。ID1のバージョン1は時刻Aに更新されて、バージョン2は時刻Bに更新されていた。

ID1,バージョン1,時刻A
ID1,バージョン2,時刻B

ってなるのか？うーん・・・何だかなぁ。