Kouhei Sutou
kou****@clear*****
2015年 10月 7日 (水) 23:56:18 JST
須藤です。 In <20151****@domai*****> "[groonga-dev,03556] Re: Mroonga で data truncated for primary key column: <id> が発生する" on Wed, 07 Oct 2015 20:04:33 +0900, 各務 洋 <kagam****@outwa*****> wrote: >> このテーブルは一度問題が発生したテーブルをそのまま使ったもの >> ですか？それとも作りなおしたものですか？ > > テスト毎にDBそのものを新しく作っていっています。 ありがとうございます。 おかげで（これと関係しそうな）問題を見つけられました。 森さん、Int64がキーなTABLE_PAT_KEYで壊れたデータになってしま うケースの再現スクリプトを作ったので見てもらえないでしょうか？ （Int64なのは関係なさそうな気はしますが。。。） https://github.com/groonga/groonga/issues/415 table_create pat TABLE_PAT_KEY Int64 load --table pat [ {"_key": 0}, {"_key": 1} ] delete pat --key 1 load --table pat [ {"_key": 3} ] select pat # -> [[0,1444229153.27227,0.00015711784362793], # [[[2],[["_id","UInt32"],["_key","Int64"]],[1,0],[1,0]]]] この最後のselectで_id,_keyが1,0のレコードが2つでています。 garbageがあるときのaddかツリーをトラバースしている処理がおか しいのかもしれません。 > そこで１点、ふと疑問に思ったのですが、Index を修復する際に、既に Unique > 違反になっているレコードはどのようにするお考えでしょうか？ Mroongaにユニークチェック中にクラッシュチェックが入ったら、 この状態になることはなくなるはずなので、考えない、が答えにな ります。 > というのも、ALTER TABLE にかける際にも、AUTO_INCREMENT 外して、Primary Key > と Unique Key 外して重複分を探して削除して元に戻す必要があったので……。 > （ALTER TABLE に失敗して Duplicate と出たら↑をやるようにしてみました） > > 私は主キーが使えないのはツラいを言い訳に、ガッと削除にしました。 重複しているものはどれかを削除するしかないです。。。 -- 須藤 功平 <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/
