lucene-dev mailing list archives

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


Uwe Schindler commented on LUCENE-1712:

I think this is simple, we just overload all ctors and factories and remove the precisionStep
there. These methods use NumericUtils.DEFAULT_PRECISION_STEP = 4 then. But thee should be
a clear not, to do also tests with other step values.

additional variants:
- NumericField(name), NumericField(name,store,index)
- NumericTokenStream()
- NumericRangeQuery.newXxxRange(field, min, max,...)

I am currentlly not sure (I was thinking the whole time during including into core) to also
make NumericRangeQuery work like the other two classes: generic Constructor without datatype
and then set the range explicit:

new NumericRangeQuery(fieldname[, precisionStep]).setFloatRange(....)

Not sure, in this case the API where similar and I have to override only one ctor for different
construction parameters. My only problem is, that Queries are normally almost everywhere in
Lucene static and unmodifable  (beyond boost).

> 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