yoku ts.
yoku0****@gmail*****
2014年 1月 28日 (火) 17:18:33 JST
こんにちは、yoku0825です :) > 丸山さん >.出来上がったインデックスを直接いじる という使い方あまり好ましくない気がします。 ううむ、悩ましいところです。 今のところアプリケーションからGroongaを直叩きやmroonga_commandはNGの方向で（変わるかもしれませんが）、 メンテナンサーがgroongaコマンド(or Rroonga)でゴニョゴニョしてやって、 アプリからはMATCH(..) AGAINST(..)だけで何とかできないかなぁと思っているので、こんなことをしているのでした :) > ぱっと思いつくのは、 > http://groonga.org/ja/docs/reference/commands/select.html#query-expander のように "ストップワード" にしてやるというのはどうでしょうか。 ありがとうございます！ 試してみます！ > 須藤さん > 追加コミットがこれで、このコミットに含まれているテストがユー > スケースを表しています。 ありがとうございます！ なんとなく理解しますた！ > これはMySQLのキャッシュじゃないかと思います。 table_open_cacheとかすごく久し振りに思い出しました。そういえばありましたねそんなキャッシュが。。 > 想定はしていませんでしたが、動くといいなとは思いました！ 俺もそう思います！ 2014年1月28日 16:56 Kouhei Sutou <kou****@clear*****>: > 須藤です。 > > In <CAHB5oTOKg_noT7sK3B=9N3++Pde15cp0ZwCUd=ghX=ocdDY****@mail*****> > "[groonga-dev,02073] ストレージモードで転置索引テーブルからレコードを削除するとデータも削除される" on Mon, 27 Jan 2014 10:44:35 +0900, > "yoku ts." <yoku0****@gmail*****> wrote: > >> 作業のログはこんな感じになるのですが、 >> >> https://gist.github.com/yoku0825/3a0f5adeba0be3aeb32f >> >> ・WHERE MATCH(val) AGAINST ('まご' IN BOOLEAN MODE)でnum= 1が引っかからないようにしたい >> ・でもWHERE num= 1では当然引っかかってほしい(データはそのまま残る) >> ・t1-valの_key== 'まご'を消せばいけるはず >> >> と思っていたのですが、カスケード削除に当たるのか、 >> t1テーブルのvalカラムがまるまる空っぽになってしまっています。 > > これは期待していない挙動です！ > > Groongaにはカスケード削除機能があって、これはインデックスのキー > を消すと、インデックス元のレコード消す機能です。もともと、こ > の機能は、全文検索用のインデックスではなく、逆引き用のインデッ > クスのために追加したものです。 > > 追加コミットがこれで、このコミットに含まれているテストがユー > スケースを表しています。 > https://github.com/groonga/groonga/commit/d488768d3eca23aadd1a429528a4054a1dcc53e3 > > ユーザーがブックマークするみたいなサービス用のケースで、URL > が消えたらユーザーのブックマークからも削除する、ということを > 実現したいケースです。URLだけ消すと、ユーザーのブックマーク > にすでに存在しないURLテーブルのレコードへの参照が残ってしま > うので、いろいろ不具合があったのです。それが起きないようにカ > スケード削除機能を追加しました。 > > ユーザーテーブル > ブックマークカラム（URLテーブル型。ベクター。） > > URLテーブル > ユーザーテーブルのブックマークカラム用のインデックス(*) > > (*) URLを指定してブックマークしているユーザー一覧を高速に検 > 索するため。 > > > で！そのときは全文検索用のインデックスのテーブルのキー（トー > クン）を削除することは想定していなかったのです！で、全文検索 > 用のインデックスで同じような挙動になるのは、変だなぁと思うの > で、期待していない挙動です！ > > 手元ではカスケード削除しないようにする変更があるんですが、今、 > コードフリーズ中なので、明日以降にpushしておきます！ > >> （ストレージモードのみで、ラッパーモードでは期待した結果になりました） > > ↑のカスケード削除機能はGroongaのデータベース機能のレイヤー > （テーブルとかカラムの関係とかを管理）のAPIで実装しているので > すが、ラッパーモードのときは、それより下のレイヤーのAPIで、イ > ンデックスを直接使っていたので関係無かったのです。 > >> また、deleteを叩いた直後はMySQLからはdelete前の情報が見えていて、 >> FLUSH TABLESなどで開きなおしてやるとdelete後の情報が見えるようになっているようです。 > > これはMySQLのキャッシュじゃないかと思います。 > >> また、↑のような「あるレコードが特定のキーワードで(のみ)マッチしないようにする」のはt1-valの_keyをいじってやる…というのはそもそも間違っていたりしますか？ > > 想定はしていませんでしたが、動くといいなとは思いました！ > > -- > 須藤 功平 <kou****@clear*****> > 株式会社クリアコード <http://www.clear-code.com/> (03-6231-7270) > > Groongaサポート: > http://groonga.org/ja/support/ > パッチ採用はじめました: > http://www.clear-code.com/recruitment/ > コミットへのコメントサービスはじめました: > http://www.clear-code.com/services/commit-comment.html > > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev
