susumu.yata
null+****@clear*****
Mon Jun 2 10:57:43 JST 2014
susumu.yata 2014-06-02 10:57:43 +0900 (Mon, 02 Jun 2014) New Revision: eb2121b99c33998c90a9ce719358251f9e1cdf54 https://github.com/groonga/grnxx/commit/eb2121b99c33998c90a9ce719358251f9e1cdf54 Message: Update TODO comments. Add in-the-future tags. Remove resolved TODOs. Add a TODO about reference-based drilldown. Modified files: new-interface/table.hpp Modified: new-interface/table.hpp (+38 -20) =================================================================== --- new-interface/table.hpp 2014-05-30 19:35:26 +0900 (42e94c7) +++ new-interface/table.hpp 2014-06-02 10:57:43 +0900 (81191de) @@ -131,14 +131,16 @@ class Table { // まとめると，返り値によって行の追加に成功したかどうかがわかり， // *result_row_id により該当する行が存在するかどうかがわかる． // - // TODO: 行 ID の再利用を無効化するオプションがあると便利かもしれない． + // TODO: 将来的な検討案． + // 行 ID の再利用を無効化するオプションがあると便利かもしれない． // 追加により割り当てられる行 ID は常に昇順という保証があれば， // 行 ID を降順に取り出すだけで新しい行から順に走査することができる． // 時刻カラムに対する索引で対応するより，ずっと効率的である． // ただし，頻繁に削除すると隙間だらけになって効率が落ちる． // オプションとしてはよさそう． // - // TODO: 削除によって行 ID に空きができたとき，前方へと詰めるという案がある． + // TODO: 将来的な検討案． + // 削除によって行 ID に空きができたとき，前方へと詰めるという案がある． // ただし，参照されているテーブルについては参照元の修正が必要になる． // また，行 ID に特別な意味を持たせている場合は問題になる． // @@ -165,14 +167,17 @@ class Table { // 依存関係の解決が許されているときは，参照元を NULL にする． // 参照元が配列になっているときは，当該要素を取り除いて前方に詰める． // - // TODO: 依存関係の解決に関する情報は，参照型のカラムに持たせることを検討中． + // TODO: 将来的な検討案． + // 依存関係の解決に関する情報は，参照型のカラムに持たせることを検討中． // SQL の ON DELETE + RESTRICT, CASCADE, SET NULL, NO ACTION に // 相当するが， NO ACTION は本当に何もしないのもありかもしれない． + // Groonga では NULL にする． // - // TODO: 参照元が配列のときは別に検討する必要がある． - // Groonga の場合は各配列から該当する参照を取り除いて前に詰める． + // TODO: 将来的な検討案． + // 参照元が配列のときは別に検討する必要がある． // 位置によって意味が変わるような使い方では問題があるため， // SET NULL も使えると嬉しいかもしれない． + // Groonga では該当する参照を取り除いて前方に詰める． // // 失敗する状況としては，以下のようなものが挙げられる． // - 指定された行が無効である． @@ -180,7 +185,8 @@ class Table { // - 依存関係を解決できるときは削除をおこなう． // - 依存関係の解決に失敗した． // - // TODO: 不要になった（参照されなくなった）タグを削除するような用途を考えると， + // TODO: 将来的な検討案． + // 不要になった（参照されなくなった）タグを削除するような用途を考えると， // 削除可能な行をすべて削除するという操作が実現できると便利そうである． // デフラグに似た専用のインタフェースを提供すべきかもしれない． virtual bool delete_row(RowID row_id, Error *error) = 0; @@ -235,7 +241,8 @@ class Table { // 返り値は std::unique_ptr なので自動的に delete される． // 自動で delete されて困るときは release() で生のポインタを取り出す必要がある． // - // TODO: 簡易なものでかまわないので，クエリ文字列をパースして式を構築してくれる + // TODO: 将来的な検討案． + // 簡易なものでかまわないので，クエリ文字列をパースして式を構築してくれる // インタフェースがあれば何かと便利かもしれない． // テスト用と考えれば，最適化などは一切せず， // 真っ正直にやってくれるのがベスト． @@ -253,13 +260,16 @@ class Table { // 成功すれば有効なオブジェクトへのポインタを返す． // 失敗したときは *error にその内容を格納し， nullptr を返す． // + // 索引との連携については，特定の条件で整列済みであることを + // 前提条件（Expression）として指示できるようにし， + // 前提条件の評価結果が一致する範囲に対して個別に整列条件を適用する． + // + // グループ化との連携については，まずグループ化をおこない， + // その後で各グループを整列するという使い方になる． + // // 返り値は std::unique_ptr なので自動的に delete される． // 自動で delete されて困るときは release() で生のポインタを取り出す必要がある． // - // TODO: 索引，整列，グループ化の連携について検討する． - // たとえば，整列の途中経過をグループ化に利用するなど． - // 行の整列とグループの整列が考えられる． - // // 失敗する状況としては，以下のようなものが挙げられる． // - オプションが不正である． // - リソースが確保できない． @@ -278,21 +288,29 @@ class Table { // 返り値は std::unique_ptr なので自動的に delete される． // 自動で delete されて困るときは release() で生のポインタを取り出す必要がある． // - // TODO: 時刻のカラムについて，月や曜日によるグループ化ができると便利である． - // 同様に値の範囲（たとえば 100 ずつ）でグループ化ができると便利である． + // 時刻を月や曜日でグループ化したり，値を 100 ずつグループ化したりするのは， + // グループ化の条件を Expression で指定できるようにすることで実現する． + // 課題は曜日などの情報を得るのにかかるオーバーヘッドを減らすことである． // - // TODO: 各グループの構成要素が必要かどうか，構成要素の数が必要かどうか， - // などのオプションによって実装を切り替えることが望ましい． - // たとえば，構成要素が不要であればハッシュ表がよさそうである． + // TODO: グループの数は未知なので，呼び出し側で確保した領域に + // グループの情報を格納するというインタフェースが使いにくい． + // そのため， Grouper に領域を確保させるか， + // グループ化の結果を少しずつ取り出せるようにするなどの工夫が必要である． // // TODO: 配列型の要素単位でグループ化する場合， // 入力された行 ID の一覧を整列する方法では対処できない． // そのため， Grouper で適当なデータ構造を用意する必要がある． // - // TODO: グループの数は未知なので，呼び出し側で確保した領域に - // グループの情報を格納するというインタフェースが使いにくい． - // そのため， Grouper に領域を確保させるか， - // グループ化の結果を少しずつ取り出せるようにするなどの工夫が必要である． + // TODO: 将来的な検討案． + // 参照型のカラム ref_col があるとき，グループ化の条件を ref_col にすれば + // 行 ID によるグループ化をおこない， ref_col._key にすれば + // 参照先のキーによるグループ化をおこなうという案がある． + // グループの順序や NULL の扱いに差が出る． + // + // TODO: 将来的な検討案． + // 各グループの構成要素が必要かどうか，構成要素の数が必要かどうか， + // などのオプションによって実装を切り替えることが望ましい． + // たとえば，構成要素が不要であればハッシュ表がよさそうである． // // 失敗する状況としては，以下のようなものが挙げられる． // - オプションが不正である． -------------- next part -------------- HTML����������������������������...Download