Susumu Yata
yata****@razil*****
2016年 3月 17日 (木) 08:44:47 JST
矢田です． 本件のエラーについては load が複数行かどうかは関係ありませんでした． 一行にしても成功と返ってくることを確認しました． また，エラーが起きると停止するように挙動を変更するオプションがあれば便利だという話を耳にしました． たしかに，選択できると便利そうです． 2016年3月16日 4:34 Yutaro Shimamura <yu****@irx*****>: > 須藤さん > 矢田さん > > ご回答ありがとうございます！ > > 通常ログを取るようにしていたのですが、バージョンアップで新しいgroongaプロセスを一時的に使っていて、 > そのことを忘れたままずっと使っていました、。 > >>> しかし！ログにはエラーが残っているのでそっちを確認してもらえ >>> ますか？ > 上にあるとおり、きちんとログに出ていました。。 > > なので元からきちんとログを取っていれば気づけた問題で。。すいません。。 > > >> 実のところ select における検出も不完全なもので，検出しやすいものしか対応していません． >> 依存関係を持つテーブルが truncate された場合などは怪しいです． >> きっちり検出してくれるとは期待しない方が良いです． > > ちなみに今回この件に当たったのは、複数のプロセスが一つのDB(インデックスなし)を開いている状態の時に > 別のプロセスで全文検索インデックスを作成したところ、 > それ以降他の起動済みプロセスのロードが検索結果に反映されなくなったことから気づきました。 > (これも再現させようと思ったのですが手元ではうまく再現しませんでした) > truncate以外にもUnmap/Reloadが必要な状態があることを認識したので、きちんとログで確認!しようと思います。 > >> load については，与えられた JSON を逐次処理すること， >> 途中でエラーを検出しても処理が止まらないようにしていること， >> 可能な範囲でデータを格納するようにしていることなどから， >> さらに問題がややこしくなっています． > >> やはり， load の途中でエラーが起きたときは，エラーを返すようにすべきでしょうか > > 何かしら正常にいかなかった時にレスポンス内にそれが確認できる手段があるといいなと思って聞いてみましたが、 > バルクロードの実装については理解しているので、loadに関してはある程度仕方ないのかもしれないですね。。＞＜ > ただ、groongaのloadが(というかsennaの時代から)長いことこの形の仕様なので、 > 別の形やコマンド等で、柔軟なloadも実現できたらいいのかな、と思いました。 > それならエラーコードだけでなく、VECTORカラムに任意の要素を一つだけ追加するみたいな機能も実現できるかな、とか‥ > > > いろいろ見渡してみたらrroongaではLoggerのregister経由でログが取れるみたいなので > ひとまずこの形を活用して正確な状態把握と問題発見をしていこうと思います。 > > > いつもご検討いただいてありがとうございます！ > > 2016-03-16 1:56 GMT+09:00 Susumu Yata <susum****@gmail*****>: >> 矢田です． >> >>> Unmap/reopenが必要な状態の時、selectではエラーコードを返してくれますが、loadの時には正常に完了した処理コードを返します。 >> >> 実のところ select における検出も不完全なもので，検出しやすいものしか対応していません． >> 依存関係を持つテーブルが truncate された場合などは怪しいです． >> きっちり検出してくれるとは期待しない方が良いです． >> >> load については，与えられた JSON を逐次処理すること， >> 途中でエラーを検出しても処理が止まらないようにしていること， >> 可能な範囲でデータを格納するようにしていることなどから， >> さらに問題がややこしくなっています． >> >> load の途中でエラーが起きてもエラーコードが返ってこない件については， >> 以下の issue が関係していると思います． >> https://github.com/groonga/groonga/issues/495 >> 現状ではヘッダ相当の部分にエラーがあるときだけエラーコードが返るようになっています． >> >> やはり， load の途中でエラーが起きたときは，エラーを返すようにすべきでしょうか． >> >> 2016年3月15日 23:22 Kouhei Sutou <kou****@clear*****>: >>> 須藤です。 >>> >>> In <E4CB1****@irx*****> >>> "[groonga-dev,03981] Unmapが必要な状態でのロードについて" on Tue, 15 Mar 2016 05:15:31 +0100, >>> Yutaro SHIMAMURA <yu****@irx*****> wrote: >>> >>>> Unmap/reopenが必要な状態の時、selectではエラーコードを返してくれますが、loadの時には正常に完了した処理コードを返します。 >>>> >>>> この時unmap対象となるテーブルは更新されておらず、値も欠損する状態なので >>>> ロードも同じようにエラーコードとかがついて判別できる状態だと良いな、と思いました。 >>> >>> loadはバルクロードなので、エラーコードで通知するのが苦手なん >>> です。戻り値のロードできたレコード数もレコードが追加されたら >>> +1するようにしていて、レコードの全カラムが追加できたら、じゃ >>> ないんで、そっちで確認することも難しいです。 >>> >>> しかし！ログにはエラーが残っているのでそっちを確認してもらえ >>> ますか？ >>> >>> 2016-03-15 23:10:50.901418|e| [table][load] failed to set column value: pat is truncated, please unmap or reopen the database: key: <"test4">, column: <test.txt>, value: <"ghi"> >>> >>> みたいなのがでているはずです。 >>> >>> >>> -- >>> 須藤 功平 <kou****@clear*****> >>> 株式会社クリアコード <http://www.clear-code.com/> >>> >>> Groongaベースの全文検索システムを総合サポート: >>> http://groonga.org/ja/support/ >>> パッチ採用 - プログラミングが楽しい人向けの採用プロセス: >>> http://www.clear-code.com/recruitment/ >>> リーダブルコードワークショップ: >>> http://www.clear-code.com/services/code-reader/readable-code-workshop.html >>> >>> _______________________________________________ >>> groonga-dev mailing list >>> groon****@lists***** >>> http://lists.osdn.me/mailman/listinfo/groonga-dev >> >> >> >> -- >> Susumu Yata <susum****@gmail*****> >> _______________________________________________ >> groonga-dev mailing list >> groon****@lists***** >> http://lists.osdn.me/mailman/listinfo/groonga-dev > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.osdn.me/mailman/listinfo/groonga-dev -- Susumu Yata <yata****@razil*****>
