0.5.6.2 をリリースしてみた。

Archtea

数字的にはちょこっとだが、Indexerは、半分ぐらい変更した。インデックスファイルに保管するUID(一応ユニークになってるはず...)フォーマット変更しちゃったので、新規作成したほうが良いかも。新規作成しなくても動きそうな気はするけど。。。

具体的には、前は

  • 更新されたやつ削除
  • 新規追加

で終わりみたいな風だったんだが、新しいのは

  • とりあえず、追加する。
  • UIDを比較して古いファイルのやつがあれば削除
  • 存在しないファイルのやつがあれば、削除

という感じにした。遅くなるかもしれないけど、確実対処で。。。

ただし、インデックス開始後に更新されたファイルは追加しない。それらは次の更新で追加するとする。なので、がんがん更新されちゃうやつは、もしかしたらさっぱりインデックスされないかもしれない。この辺は、もうちょっと調べて問題なさそうなら、その場で追加するような場合も考えることにしよう。

とりあえず、今回の目標は前回の0.5.6.1で、更新ファイルとかあるとIndexされる文書が減っちゃうのはやっぱまずいよね、というのの対処と、エラーがあってもどんどん次に進むようにしたこと。ただ、ほんまは、エラーがあったら停止ってのもやらないと、ほんまにファイルシステムのエラーがあるときに延々とうごいちゃうからね。。その辺は、最大値とかを設定できるようにしたほうがええんだろうのぅ。

このアプリ、Zipの中もインデックスしたいから、ファイル絶対パス+最終更新日が使えない場合がある。なので、色々試行錯誤したがなんとか動いているようだ。もしかしたら、だめなパターンがあるかもしれないが。それにしても、今回の変更は、昔にちまちまテストケースつくってあったのが効いた。試しに動かしてみたら、登録文書が多かったり、変なエラーが出たり。。。やっぱり、Unitテスト作っとくと後から効いてくる。RubyOnRailsとかも、作るのはお手軽だけど、テストをちゃんとつくっとかないと、維持するの大変だろうな。Javaみたく型保証みたいなのがないから、変な変更をしたら、コンパイルエラーとかないし。実行してみないとうまくいかないみたいな場合がありそうだからね。

Luceneって、各文書に番号がふられているとしても、同じ内容を登録できちゃったりは当然するので、ちゃんとユニークな文字列とかをつかわないと同じ文書が2個登録されちゃったりする。追加したあと、削除とかやっちゃって、IDみたいなのが同じだと両方削除される。なので、その辺はちゃんとチェックが今回はちっと大変だった。いまんとこは大丈夫みたいだが実際はどうだろう。。