Re: TrieField and FieldCache confusion

2013-08-01 Thread Paul Masurel
Thank you very much for your very fast answer and
all the pointers.

That's what I thought, but then I got confused by the last note
http://wiki.apache.org/solr/StatsComponent

TrieFields http://wiki.apache.org/solr/TrieFields has to use a
precisionStep of -1 to avoid using
UnInvertedFieldhttp://wiki.apache.org/solr/UnInvertedField.java.
Consider using one field for doing stats, and one for doing range facetting
on. 

I assume it referred to former version of Solr.




On Wed, Jul 31, 2013 at 7:43 PM, Chris Hostetter
hossman_luc...@fucit.orgwrote:


 : Can I expect the FieldCache of Lucene to return the correct values when
 : working
 : with TrieField with the precisionStep higher than 0. If not, what did I
 get
 : wrong?

 Yes -- the code for building FieldCaches from Trie fields is smart enough
 to ensure that only the real original values are used to populate the
 Cache

 (See for example: FieldCache.NUMERIC_UTILS_INT_PARSER and the classes
 linked to from it's javadocs...


 https://lucene.apache.org/core/4_4_0/core/org/apache/lucene/search/FieldCache.html#NUMERIC_UTILS_INT_PARSER

 https://lucene.apache.org/core/4_4_0/core/org/apache/lucene/util/NumericUtils.html

 https://lucene.apache.org/core/4_4_0/core/org/apache/lucene/document/IntField.html

 (Solr's Trie fields are backed by the various numeric fields in lucene --
 ie: solr:TrieIntField - lucene:IntField.  the Trie* prefix is used in
 solr because there already had classes named IntField, DoubleField, etc...
 when the Trie based impls where added to lucene)


 -Hoss




-- 
__

 Masurel Paul
 e-mail: paul.masu...@gmail.com


TrieField and FieldCache confusion

2013-07-31 Thread Paul Masurel
Hello everyone,

I have a question about Solr TrieField and Lucene FieldCache.

From my understanding, Solr added the implementation of TrieField to
perform faster range queries.
For each value it will index multiple terms. The n-th term being a masked
version of our value,
showing only it first (precisionStep * n) bits.

When uninverting the field to populate a FieldCache, the last value with
regard
to the lexicographical order will be retained ; which from my understanding
should
be the term with the highest precision.

Can I expect the FieldCache of Lucene to return the correct values when
working
with TrieField with the precisionStep higher than 0. If not, what did I get
wrong?

Regards,

Paul Masurel
e-mail: paul.masu...@gmail.com


Re: TrieField and FieldCache confusion

2013-07-31 Thread Chris Hostetter

: Can I expect the FieldCache of Lucene to return the correct values when
: working
: with TrieField with the precisionStep higher than 0. If not, what did I get
: wrong?

Yes -- the code for building FieldCaches from Trie fields is smart enough 
to ensure that only the real original values are used to populate the 
Cache

(See for example: FieldCache.NUMERIC_UTILS_INT_PARSER and the classes 
linked to from it's javadocs...

https://lucene.apache.org/core/4_4_0/core/org/apache/lucene/search/FieldCache.html#NUMERIC_UTILS_INT_PARSER
https://lucene.apache.org/core/4_4_0/core/org/apache/lucene/util/NumericUtils.html
https://lucene.apache.org/core/4_4_0/core/org/apache/lucene/document/IntField.html

(Solr's Trie fields are backed by the various numeric fields in lucene -- 
ie: solr:TrieIntField - lucene:IntField.  the Trie* prefix is used in 
solr because there already had classes named IntField, DoubleField, etc... 
when the Trie based impls where added to lucene)


-Hoss