lucene-dev mailing list archives

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

    [ https://issues.apache.org/jira/browse/LUCENE-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722839#action_12722839
] 

Uwe Schindler commented on LUCENE-1712:
---------------------------------------

The methods setFloatValue() etc are for specifying the exact data type. If you would do it
in the constructor, the resulting code would be very error-prone. e.g., new NumericField("price",
12.5): Does this mean 12.5 as double or float, is 15 alone meant as (in future) short, byte
or int? OK users can add "f" in the float case to it, but this makes it very hard to prevent
errors, because Java automatically casts all numeric types to each other suddenly. This is
why I added these factories for NumericRangeQuery and the setters here.

> 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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message