-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Value type hint as string #80838
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
Value type hint as string #80838
Conversation
The goal of this change is to let numeric script values sources know if they are floating point or not. Previously, this was done by plumbing the ValueType deep into the ValuesSource. Now, instead, pass in a boolean, but that in turn requires the VST to know if it's floating point or not. Thus this split.
@@ -1389,16 +1388,20 @@ public void testScriptWithValueType() throws Exception { | |||
assertThat(terms.getBuckets().size(), equalTo(1)); | |||
} | |||
|
|||
String invalidValueType = source.replaceAll("\"value_type\":\"n.*\"", "\"value_type\":\"foobar\""); | |||
String invalidValueType = source.replaceAll("\"value_type\":\"n.*?\"", "\"value_type\":\"foobar\""); |
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.
Regexes are hard. This test has always produced invalid json here, but apparently in the old code path we failed on value type validation first. Stream parsing I guess.
XContentParseException ex = expectThrows( | ||
XContentParseException.class, | ||
SearchPhaseExecutionException ex = expectThrows( | ||
SearchPhaseExecutionException.class, |
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.
We no longer catch invalid value types at parse time. We do still catch them before aggregation execution though (at ValuesSourceConfig#Resolve time).
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.
The change look reasonable to me. Since it is pretty big, I might have missed something. So, it might make sense for @nik9000 to have another look as well.
) { | ||
this.aggregatorRegistry = copyMap(aggregatorRegistry); | ||
this.usageService = usageService; | ||
// TODO: Make an immutable copy blah blah blah |
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.
Is this planned for a follow-up?
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.
yeah, I skipped it for time when doing the initial draft, but I'll add that in before merging. Thanks for the reminder. Probably a few other small clean ups I need to do too (like fixing the merge conflicts...).
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.
I think there are two outwards facing changes.
- Aggs can declare different support for
long
vsdouble
. I wonder if we can dropisFloatingPoint
in a follow up change and have aggs declare support forlong
anddouble
separately instead of checking that. - Plugins can now declare new values source types. Aggs won't support them out of the box, but the plugin could declare those too. That's neat.
I think I found a NOCOMMIT
that snuck in. I left a few small requests otherwise.
assertDiff(beforeCombinedAggsUsage, afterCombinedAggsUsage, "terms", "date", 1L); | ||
assertDiff(beforeCombinedAggsUsage, afterCombinedAggsUsage, "terms", "keyword", 2L); | ||
assertDiff(beforeCombinedAggsUsage, afterCombinedAggsUsage, "avg", "numeric", 3L); | ||
assertDiff(beforeCombinedAggsUsage, afterCombinedAggsUsage, "avg", "long", 3L); |
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.
Does this one also want to have double
here?
protected NumericValuesSourceParser(boolean formattable) { | ||
super(formattable, CoreValuesSourceType.NUMERIC, ValueType.NUMERIC); | ||
super(formattable, CoreValuesSourceType.DOUBLE, ValueType.NUMERIC); |
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.
It's probably best not to drop support for anything in a big refactoring PR. Maybe make sure we have a test that targets a long
field?
@@ -59,6 +61,8 @@ public int hashCode() { | |||
public static class Builder { | |||
private final AggregationUsageService.Builder usageServiceBuilder; | |||
private Map<RegistryKey<?>, List<Map.Entry<ValuesSourceType, ?>>> aggregatorRegistry = new HashMap<>(); | |||
private Map<String, ValuesSourceType> valueTypeLookup = new HashMap<>(); | |||
private Set<ValuesSourceType> duplicateRegistrationCheck = new HashSet<>(); |
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.
Maybe just registeredValuesSourceTypes
. It isn't just for dupes.
@@ -981,7 +981,8 @@ private void writeTestDoc(MappedFieldType fieldType, String fieldName, RandomInd | |||
Document doc = new Document(); | |||
String json; | |||
|
|||
if (vst.equals(CoreValuesSourceType.NUMERIC)) { | |||
// NOCOMMI: Break out long and double logic? |
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.
NOTCOMMIT?
@@ -203,7 +207,8 @@ private ValuesSourceConfig toConfig(SortedNumericDocValues values) throws IOExce | |||
when(source.isFloatingPoint()).thenReturn(false); | |||
when(source.longValues(null)).thenReturn(values); | |||
if (randomBoolean()) { | |||
return toConfig(source, CoreValuesSourceType.NUMERIC, randomWholeNumberDocValuesFormat(), true); | |||
// TODO: should we have a case for CVST.LONG here? | |||
return toConfig(source, CoreValuesSourceType.DOUBLE, randomWholeNumberDocValuesFormat(), true); |
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.
It's probably worth it now that they are separate types. But it's not a blocker for this at all.
Pinging @elastic/es-analytics-geo (Team:Analytics) |
Pinging @elastic/es-analytical-engine (Team:Analytics) |
there's no path to merging this at this point. |
Resolves #53424
This stores user value type hints internally as strings, converting them to
ValuesSourceTypes
at config resolution time.