Maruyama Kenji
mmmar****@gmail*****
2014年 1月 28日 (火) 16:50:04 JST
こんにちわ。丸山です。 > 作業のログはこんな感じになるのですが、 > > https://gist.github.com/yoku0825/3a0f5adeba0be3aeb32f > > ・WHERE MATCH(val) AGAINST ('まご' IN BOOLEAN MODE)でnum= 1が引っかからないようにしたい > ・でもWHERE num= 1では当然引っかかってほしい(データはそのまま残る) > ・t1-valの_key== 'まご'を消せばいけるはず > > と思っていたのですが、カスケード削除に当たるのか、 > t1テーブルのvalカラムがまるまる空っぽになってしまっています。 > （ストレージモードのみで、ラッパーモードでは期待した結果になりました） > > また、deleteを叩いた直後はMySQLからはdelete前の情報が見えていて、 > FLUSH TABLESなどで開きなおしてやるとdelete後の情報が見えるようになっているようです。 詳しいログまでありがとうございます。 > これは想定内の動作でになりますか？ 想定内かどうかは まずは手元で再現してみますね。 > また、↑のような「あるレコードが特定のキーワードで(のみ)マッチしないようにする」のはt1-valの_keyをいじってやる…というのはそもそも間違っていたりしますか？ 出来上がったインデックスを直接いじる という使い方あまり好ましくない気がします。 ぱっと思いつくのは、 http://groonga.org/ja/docs/reference/commands/select.html#query-expander のように "ストップワード" にしてやるというのはどうでしょうか。 On 2014/01/27, at 10:44, yoku ts. <yoku0****@gmail*****> wrote: > こんにちは、yoku0825といいます。 > > Mroongaのストレージモードから投入されたデータの転置索引を > groongaコマンドでごにょごにょしたいと考えているのですが、 > 掲題のような不思議な状態になったので教えていただきたいです。 > > 作業のログはこんな感じになるのですが、 > > https://gist.github.com/yoku0825/3a0f5adeba0be3aeb32f > > ・WHERE MATCH(val) AGAINST ('まご' IN BOOLEAN MODE)でnum= 1が引っかからないようにしたい > ・でもWHERE num= 1では当然引っかかってほしい(データはそのまま残る) > ・t1-valの_key== 'まご'を消せばいけるはず > > と思っていたのですが、カスケード削除に当たるのか、 > t1テーブルのvalカラムがまるまる空っぽになってしまっています。 > （ストレージモードのみで、ラッパーモードでは期待した結果になりました） > > また、deleteを叩いた直後はMySQLからはdelete前の情報が見えていて、 > FLUSH TABLESなどで開きなおしてやるとdelete後の情報が見えるようになっているようです。 > > これは想定内の動作でになりますか？ > また、↑のような「あるレコードが特定のキーワードで(のみ)マッチしないようにする」のはt1-valの_keyをいじってやる…というのはそもそも間違っていたりしますか？ > > どうぞよろしくお願いします。。 > > > /* yoku0825 */ > > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev
