New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update default precision step, modulo tests #5908
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -20,7 +20,7 @@ | |
package org.elasticsearch.index.analysis; | ||
|
||
import com.carrotsearch.hppc.IntObjectOpenHashMap; | ||
import org.apache.lucene.util.NumericUtils; | ||
import org.elasticsearch.index.mapper.core.FloatFieldMapper; | ||
|
||
import java.io.IOException; | ||
import java.io.Reader; | ||
|
@@ -51,7 +51,7 @@ public static NamedAnalyzer buildNamedAnalyzer(int precisionStep) { | |
private final int precisionStep; | ||
|
||
public NumericFloatAnalyzer() { | ||
this(NumericUtils.PRECISION_STEP_DEFAULT); | ||
this(FloatFieldMapper.DEFAULT_PRECISION_STEP); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this seems unused anyways I think we should just drop these default ctors? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good. I didnt yet look to see how they are used. |
||
} | ||
|
||
public NumericFloatAnalyzer(int precisionStep) { | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -62,6 +62,7 @@ | |
public class ByteFieldMapper extends NumberFieldMapper<Byte> { | ||
|
||
public static final String CONTENT_TYPE = "byte"; | ||
public static final int DEFAULT_PRECISION_STEP = Integer.MAX_VALUE; // 256 terms max! | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think think this constant should be set to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. aaah nevermind - that is all static.... grrr... It seems like we should add There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good. Wasn't sure if we want to do it all based on bitness. In general I have not had time to think about each type. For example, to me 8 is intuitive for an IP-address type, regardless of what the default is for Integer. |
||
|
||
public static class Defaults extends NumberFieldMapper.Defaults { | ||
public static final FieldType FIELD_TYPE = new FieldType(NumberFieldMapper.Defaults.FIELD_TYPE); | ||
|
@@ -78,7 +79,7 @@ public static class Builder extends NumberFieldMapper.Builder<Builder, ByteField | |
protected Byte nullValue = Defaults.NULL_VALUE; | ||
|
||
public Builder(String name) { | ||
super(name, new FieldType(Defaults.FIELD_TYPE)); | ||
super(name, new FieldType(Defaults.FIELD_TYPE), DEFAULT_PRECISION_STEP); | ||
builder = this; | ||
} | ||
|
||
|
@@ -346,7 +347,7 @@ public void merge(Mapper mergeWith, MergeContext mergeContext) throws MergeMappi | |
protected void doXContentBody(XContentBuilder builder, boolean includeDefaults, Params params) throws IOException { | ||
super.doXContentBody(builder, includeDefaults, params); | ||
|
||
if (includeDefaults || precisionStep != Defaults.PRECISION_STEP) { | ||
if (includeDefaults || precisionStep != DEFAULT_PRECISION_STEP) { | ||
builder.field("precision_step", precisionStep); | ||
} | ||
if (includeDefaults || nullValue != null) { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
man those seem to be trappy - maybe we should deprecate them in Lucene as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, see https://issues.apache.org/jira/browse/LUCENE-5605