Apache
/
lucene
mirror of https://github.com/apache/lucene.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

LUCENE-1872: Javadocs updates of Numeric* 

git-svn-id: https://svn.apache.org/repos/asf/lucene/java/trunk@815195 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Uwe Schindler 2009-09-15 07:28:27 +00:00
parent 4666489857
commit 95d3f4bd52
2 changed files with 8 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
src/java/org/apache/lucene/document/NumericField.java
View File

@ -107,6 +107,10 @@ import org.apache.lucene.search.FieldCache; // javadocs
* like to change the value. Note that you must also
* specify a congruent value when creating {@link
* NumericRangeQuery} or {@link NumericRangeFilter}.
* For low cardinality fields larger precision steps are good.
* If the cardinality is < 100, it is fair
* to use {@link Integer#MAX_VALUE}, which produces one
* term per value.
*
* <p>For more information on the internals of numeric trie
* indexing, including the <a

4
src/java/org/apache/lucene/search/NumericRangeQuery.java
View File

@ -133,11 +133,15 @@ import org.apache.lucene.index.Term;
* <li>The default for all data types is <b>4</b>, which is used, when no <code>precisionStep</code> is given.
* <li>Ideal value in most cases for <em>64 bit</em> data types <em>(long, double)</em> is <b>6</b> or <b>8</b>.
* <li>Ideal value in most cases for <em>32 bit</em> data types <em>(int, float)</em> is <b>4</b>.
* <li>For low cardinality fields larger precision steps are good. If the cardinality is &lt; 100, it is
* fair to use {@link Integer#MAX_VALUE} (see below).
* <li>Steps <b>&ge;64</b> for <em>long/double</em> and <b>&ge;32</b> for <em>int/float</em> produces one token
* per value in the index and querying is as slow as a conventional {@link TermRangeQuery}. But it can be used
* to produce fields, that are solely used for sorting (in this case simply use {@link Integer#MAX_VALUE} as
* <code>precisionStep</code>). Using {@link NumericField NumericFields} for sorting
* is ideal, because building the field cache is much faster than with text-only numbers.
* These fields have one term per value and therefore also work with term enumeration for building distinct lists
* (e.g. facets / preselected values to search for).
* Sorting is also possible with range query optimized fields using one of the above <code>precisionSteps</code>.
* </ul>
*