Skip to content

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

Closed
wants to merge 21 commits into from

Conversation

not-napoleon
Copy link
Member

Resolves #53424

This stores user value type hints internally as strings, converting them to ValuesSourceTypes at config resolution time.

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\"");
Copy link
Member Author

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,
Copy link
Member Author

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

@not-napoleon not-napoleon requested review from imotov and nik9000 January 4, 2022 21:32
Copy link
Contributor

@imotov imotov left a 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
Copy link
Contributor

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?

Copy link
Member Author

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

Copy link
Member

@nik9000 nik9000 left a 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.

  1. Aggs can declare different support for long vs double. I wonder if we can drop isFloatingPoint in a follow up change and have aggs declare support for long and double separately instead of checking that.
  2. 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);
Copy link
Member

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);
Copy link
Member

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<>();
Copy link
Member

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?
Copy link
Member

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);
Copy link
Member

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.

@mark-vieira mark-vieira removed the v8.1.0 label Feb 2, 2022
@elasticsearchmachine elasticsearchmachine added the needs:triage Requires assignment of a team area label label Jul 27, 2022
@nik9000 nik9000 removed the needs:triage Requires assignment of a team area label label Aug 2, 2022
@elasticsearchmachine elasticsearchmachine added the needs:triage Requires assignment of a team area label label Aug 2, 2022
@nik9000 nik9000 removed the needs:triage Requires assignment of a team area label label Aug 2, 2022
@elasticsearchmachine elasticsearchmachine added the needs:triage Requires assignment of a team area label label Aug 2, 2022
@romseygeek romseygeek added :Analytics/Aggregations Aggregations and removed needs:triage Requires assignment of a team area label labels Aug 16, 2022
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-analytics-geo (Team:Analytics)

@elasticsearchmachine elasticsearchmachine added the Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) label Aug 16, 2022
@csoulios csoulios added v8.6.0 and removed v8.5.0 labels Sep 21, 2022
@kingherc kingherc added v8.7.0 and removed v8.6.0 labels Nov 16, 2022
@rjernst rjernst added v8.8.0 and removed v8.7.0 labels Feb 8, 2023
@gmarouli gmarouli added v8.9.0 and removed v8.8.0 labels Apr 26, 2023
@quux00 quux00 added v8.11.0 and removed v8.10.0 labels Aug 16, 2023
@mattc58 mattc58 added v8.12.0 and removed v8.11.0 labels Oct 4, 2023
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-analytical-engine (Team:Analytics)

@not-napoleon
Copy link
Member Author

there's no path to merging this at this point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Analytics/Aggregations Aggregations Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) v8.14.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Parse user type hints directly to ValuesSourceTypes