On Mon, Oct 25, 2010 at 9:00 AM, Steven A Rowe <sar...@syr.edu> wrote: > It's not actually deprecated yet.
you are right! only in my patch! > AFAICT, Test2BTerms only deals with the indexing side of this issue, and > doesn't test searching. > > LUCENE-2551 does, however, test searching. Why hasn't this been committed > yet? I had just assumed that it was because fully indexable/searchable > binary terms were not yet ready for prime time. > > I hadn't realized that native binary terms were fully functional - is there > any reason why integers (for example) could not be directly > indexable/searchable? they are! Term itself now holds a BytesRef behind the scenes, and pretty much everything is fully-functional (for example, the collated sort use case works with the patch in LUCENE-2551) But, the short answer is we still need to fix TermRangeQuery to just work on bytes. The problem is i didnt link the dependent issue: LUCENE-2514 (I just did this) There is a patch to fix all the range query stuff there... its not finished but not far. The basic idea is to make using [ICU]CollationAnalyzer the supported way of doing this, including queryparser support, etc. The long answer is even after LUCENE-2514 is resolved, there are still some things to figure out: for example how should we properly expose stuff like this in Solr? Do we really need to modify the TokenizerFactories to take AttributeFactory and add "AttributeFactoryFactory"? Or is it better to add a Solr fieldtype for these kind of things, and do it that way? Or we could just add a special "CollatedKeywordTokenizerFactory" with the current model that supports the sorting use case easily, but we still want range query support I think...
