> * Was the field even indexed w/ Trie, or indexed as "simple text"? > It's useful to know this "automatically" at search time, so eg a > RangeQuery can do the right thing by default. FieldInfos seems > like the natural place to store this. It's basically Lucene's > per-segment write-once schema. Eg we use this to record "did any > token in this field have a Payload?", which is analogous. This should really be in a schema of some kind (like in my project for instance). Why do you do autodetection for tries, but recently removed it for FieldCache? Things should be concise, either store all settings in the index (and die in the process), or don't store them there at all.
> * We have a bug (or an important improvement) in how Trie encodes > terms that we need to fix. This one is not easy to handle, since > such a change could alter the term order, and merging segments > then becomes problematic. Not sure how to handle that. Yonik, > has Solr ever had to make a change to NumberUtils? There are cases when reindexing is inevitable. What so horrible about it anyway? Even if you have a humongous index, you can rebuild it in a matter of days, and you don't do this often. -- Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com) Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 ICQ: 104465785 --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org