lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] Commented: (LUCENE-1712) Set default precisionStep for NumericField and NumericRangeFilter
Date Mon, 22 Jun 2009 22:54:07 GMT


Hoss Man commented on LUCENE-1712:

behind the scenes precision changes based on which set*Value() method is called smells really

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...

NumericField a = new NumericField("price", MY_CUSTOM_PRECISION_STEP, ...);
a.setFloatValue(23.4f); // blows away my custom precision

NumericField b = new NumericField("price", ...);
b.setFloatValue(23.4f); // blows away my custom precision

NumericField c = new NumericField("price", ...);
c.setPrecisionStep(MY_CUSTOM_PRECISION_STEP); // only way to get my value used

...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.

int DEFAULT_STEP = ...;

> Set default precisionStep for NumericField and NumericRangeFilter
> -----------------------------------------------------------------
>                 Key: LUCENE-1712
>                 URL:
>             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:
For additional commands, e-mail:

View raw message