Hi Otis,
This is needed, because it is not enough to simply add the encoded field value
as one term. TrieRangeFilter needs additional terms with lower precision to
match many documents with few lower precision terms in the center of the range.
The helper method is needed to generate the additional terms. The additional
terms have a field name with "#trie" appended. This is needed to be able to
sort against trie encoded fields (one term per doc in sortable fields).
I will change the tabs with some further update.
Uwe
---- Originalnachricht ----
Von: Otis Gospodnetic <otis_gospodne...@yahoo.com>
Gesendet:
An: java-dev@lucene.apache.org
Betreff: TrieUtils question
Hello,
I'm late looking into Uwe's Trie contrib (nice work!), but while looking at the
code/docs for it I wondered why the
following API (TrieUtils):
// add some numerical fields:
double fvalue = 1.057E17;
TrieUtils.VARIANT_8BIT.addDoubleTrieCodedDocumentField(doc,
"exampleDouble", fvalue, true /* index the field */, Field.Store.YES);
Why not just have a method that returns an appropriately encoded value instead
of passing in a Document instance and getting TrieUtils be concerned with
adding fields to documents? I guess various *trieCoded* methods do what I'm
describing, but then why even have those add*DocumentField methods? Zucker?
Uwe, mind converting tabs to 2 spaces?
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
