Ryo Onodera
onode****@clear*****
2009年 12月 15日 (火) 11:24:20 JST
小野寺です。 分かりました。それではGRN_TABLE_VIEWのダンプ機能の対応はしないことにしま す。 On Mon, 2009-12-14 at 21:22 +0900, morit****@razil***** wrote: > 森です。 > > ご指摘ありがとうございます。 > > すみません。。dump機能は実テーブルに対してのみ行うようにしたいと思います。 > > >>> Ryo Onodera さんは書きました： > > 小野寺です。 > > > > 本家のリポジトリにpushする前に確認したいことがありましたので、私のリポジ > > トリに次のコミットをpushしました。 > > > > support view tables to dump > > http://github.com/ryoqun/groonga/commit/eb19dee2642348fea89544899a567cd29a27cd4c > > > > このコミットではGRN_TABLE_VIEWのdumpに対応させていますが、実装するため > > に、grn_view構造体の定義がlib/proc.cで必要となりました。その構造体は > > lib/db.c内で定義されているので、lib/proc.cからはアクセスすることができ > > ず、このパッチではgrn_view構造体の定義をlib/db.cからlib/db.hに暫定的に移 > > 動し、viewテーブルのダンプの実装を行いました。それが、このコミットを直接 > > 本家リポジトリにpushしなかった理由です。 > > > > それで、これを期にdumpの関連のコードが多くなってきましたし、それらを > > grn_selectやgrn_loadなどのようにlib/db.cに移動させ、lib/proc.cの > > proc_dumpはgrn_dumpを呼ぶようにしたほうがいいのでは無いかと考えていま > > す。 > > > > 実は同じようなことが前に起きまして、その時は、grn_accessorの定義が > > lib/proc.cで必要になりましたが、work aroundすることができました。が、今 > > 回は難しそうです。 > > > > grn_viewやgrn_accessorは外に見せるべきでは無いと思いますし、構造体の定義 > > をlib/db.hに移すよりは、コードを移動させたほうがいいような気がしますが、 > > 懸念としては、ただでさえ、かなり長いlib/db.cがさらに長くなってしまうとい > > うことです。 > > > > -- > > 小野寺 諒 <onode****@clear*****> > > 株式会社クリアコード (http://www.clear-code.com/) > > > > _______________________________________________ > > groonga-dev mailing list > > groon****@lists***** > > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev > > > -- > morita
