カテゴリIDから、所属するデータIDを引っ張ってくるINDEX(C2D)のテストケース。
がとりあえず終了。うーん、用法としては多分本来の使い方ではないのだろうけれども、テストケースを先に書くのは、こうした、未経験レイヤーのI/Fを作るときの「ラフスケッチ」として結構有効。実装を先に書いちゃうと、どうしてもI/Fを直すのが億劫になってしまうからね。先に実装したメソッドとかだと余計に。
とはいえ、まぁどうせテストケース自体もこの先変わっていくわけで、I/Fもずるずる変わっていくのだろうから・・・まぁその時はその時。あくまでも、「初めての」と言うときのラフスケッチ「にも」有効ですよ、ということなのだろう。
で、I/F。
えっと、昨日の時点で、一口に「INDEX」と言っても大雑把に次の二種類に大別できるところまでは考えていました。
- Relational Index
- 要するにサブテーブルとの関係づけ。1:N, N:Nのマッピングを牽くためのもの。
- Sort Index
- ソート(作成日時とか更新日時とかがドンピシャ)を高速化するためのもの。
これらそれぞれに、また、さらにその中の実際の実装毎に、いろんな物理ファイルの持ち方があります。で、この辺は実際どう共通パターンがあるのかとかはまだ見えていません。（というかこういった領域のプログラミング自体が初めて。）
なので、テストケース・・・というかI/Fレベルとしては、インデックスを納める「ディレクトリ」までは指示しますし、Indexオブジェクトも自分が使用しているインデックスディレクトリ名を公開します。但し、その中でどういった物理ファイル構成を採っているのかまでは外部には見せない、気にしないこととします。Relational Indexであれば、全レコードを1ファイルに納めるかもしれませんし、あるいはID毎にファイルをバラしているかもしれません。Sort Indexであれば、また独自の形で持つかも知れません。それらは現時点では予想しきれないので、考えないこととします。
作っていけばどうにかなるさ、きっと！！
今回作ったテストケースは、カテゴリIDから、それと関連づけられたデータIDを取得・操作する。つまりRelational Indexに相当する。
作ったI/Fはこんな感じ。
- create($cid)
- カテゴリIDのエントリを作成する。
- drop($cid)
- カテゴリIDのエントリを削除する。データIDが未登録の、空のエントリのみ削除できる。
- exist($cid)
- 指定したカテゴリIDのエントリが存在するかを返す。
- count_for($cid)
- 指定したカテゴリIDのエントリ中の、データIDの個数を返す。
ここまでがカテゴリIDのエントリを丸ごと操作するI/F。で、ここからは実際のデータIDに対して操作するI/F。
- get_from($cids)
- カテゴリIDに関連したデータIDの配列を返す。$cidは配列の形で複数指定することも可能。返値はカテゴリIDをキーとしたデータID配列、の連想配列。
- add($did, $cids)
- データIDを、指定したカテゴリID群に追加する。 登録済の場合は無視される。返値は、影響を受けたカテゴリIDの数。
- remove($did, $cids)
- データIDを、指定したカテゴリID群から削除する。未登録の場合は無視される。返値は、影響を受けたカテゴリIDの数。
いわゆる本格的なRDBにおいて、INDEXの操作I/Fがどうなっているのか・・・。全然見ないで作ってるので、ひょっとしたら将来的にものすごーーーーく変更される可能性が高いかも。
まぁいいや。後で考えよう。
ということで実装行ってみるか・・・。
