[
https://issues.apache.org/jira/browse/LUCENE-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722878#action_12722878
]
Hoss Man commented on LUCENE-1712:
----------------------------------
behind the scenes precision changes based on which set*Value() method is called
smells really wrong.
I'm not overly familiar with NumericField, but i'm i'm understanding the
current suggestion, wouldn't that mkae situations like this come up...
{code}
NumericField a = new NumericField("price", MY_CUSTOM_PRECISION_STEP, ...);
a.setFloatValue(23.4f); // blows away my custom precision
NumericField b = new NumericField("price", ...);
b.setPrecisionStep(MY_CUSTOM_PRECISION_STEP);
b.setFloatValue(23.4f); // blows away my custom precision
NumericField c = new NumericField("price", ...);
c.setFloatValue(23.4f);
c.setPrecisionStep(MY_CUSTOM_PRECISION_STEP); // only way to get my value used
{code}
...that seems sketchy, and really anoying if people try reusing NumericField
instances.
If the goal is to have good "defaults" based on type then why not just have a
constant per type that people can refer to explicitly? if they don't know what
number to pick ... as well as a true "default" if they pick nothing.
{code}
int DEFAULT_STEP = ...;
int SUGGESTED_INT_STEP = ...;
int SUGGESTED_FLOAT_STEP = ...;
{code}
> Set default precisionStep for NumericField and NumericRangeFilter
> -----------------------------------------------------------------
>
> Key: LUCENE-1712
> URL: https://issues.apache.org/jira/browse/LUCENE-1712
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 2.9
> Reporter: Michael McCandless
> Priority: Minor
> Fix For: 2.9
>
>
> This is a spinoff from LUCENE-1701.
> A user using Numeric* should not need to understand what's
> "under the hood" in order to do their indexing & searching.
> They should be able to simply:
> {code}
> doc.add(new NumericField("price", 15.50);
> {code}
> And have a decent default precisionStep selected for them.
> Actually, if we add ctors to NumericField for each of the supported
> types (so the above code works), we can set the default per-type. I
> think we should do that?
> 4 for int and 6 for long was proposed as good defaults.
> The default need not be "perfect", as advanced users can always
> optimize their precisionStep, and for users experiencing slow
> RangeQuery performance, NumericRangeQuery with any of the defaults we
> are discussing will be much faster.
--
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: [email protected]
For additional commands, e-mail: [email protected]