[
https://issues.apache.org/jira/browse/LUCENE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722820#action_12722820
]
Michael McCandless commented on LUCENE-1701:
--------------------------------------------
bq. Using 4 for int, 6 for long.
Unfortunately we can't easily conditionalize the default by int vs long. Ie
use you NumericField like this:
{code}
NumericField f = new NumericField("price", 4);
f.setFloatValue(15.50);
{code}
bq. Mike: As you see, the precision step is a good config approach, so an
default is should be choosen carefully.
Agreed! But, it need not be "perfect". Advanced users can test & iterate to
find the best tradeoff for their particular field's value distribution. For
slow ranges now with RangeQuery (because of many unique terms),
NumericRangeQuery will be a massive speedup with eg a default of 4.
New users shouldn't have to understand what precisionStep means, or anything
about "what's under the hood", in order to use NumericField. I should be able
to simply:
{code}
new NumericField("price", 15.50);
{code}
Erring towards more terms (and faster searches) is fine, I think, because in a
"typical" index the text fields with dwarf any small added disk space (hence my
proposal of 4 as the default precisionStep).
bq. Can you open an issue?
OK I'll open a new issue.
> Add NumericField and NumericSortField, make plain text numeric parsers public
> in FieldCache, move trie parsers to FieldCache
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-1701
> URL: https://issues.apache.org/jira/browse/LUCENE-1701
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Index, Search
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 2.9
>
> Attachments: LUCENE-1701-test-tag-special.patch, LUCENE-1701.patch,
> LUCENE-1701.patch, LUCENE-1701.patch, LUCENE-1701.patch, LUCENE-1701.patch,
> LUCENE-1701.patch, NumericField.java
>
>
> In discussions about LUCENE-1673, Mike & me wanted to add a new NumericField
> to o.a.l.document specific for easy indexing. An alternative would be to add
> a NumericUtils.newXxxField() factory, that creates a preconfigured Field
> instance with norms and tf off, optionally a stored text (LUCENE-1699) and
> the TokenStream already initialized. On the other hand
> NumericUtils.newXxxSortField could be moved to NumericSortField.
> I and Yonik tend to use the factory for both, Mike tends to create the new
> classes.
> Also the parsers for string-formatted numerics are not public in FieldCache.
> As the new SortField API (LUCENE-1478) makes it possible to support a parser
> in SortField instantiation, it would be good to have the static parsers in
> FieldCache public available. SortField would init its member variable to them
> (instead of NULL), so making code a lot easier (FieldComparator has this ugly
> null checks when retrieving values from the cache).
> Moving the Trie parsers also as static instances into FieldCache would make
> the code cleaner and we would be able to hide the "hack"
> StopFillCacheException by making it private to FieldCache (currently its
> public because NumericUtils is in o.a.l.util).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
