Skip to content
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

Scripted keyword field type: update family type and test field caps output #59672

Conversation

javanna
Copy link
Member

@javanna javanna commented Jul 15, 2020

Relates to #59332

@javanna javanna added the :Search/Search Search-related issues that do not fall into other categories label Jul 15, 2020
@javanna javanna requested a review from nik9000 July 15, 2020 21:07
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search (:Search/Search)

@elasticmachine elasticmachine added the Team:Search Meta label for search team label Jul 15, 2020
@javanna javanna mentioned this pull request Jul 15, 2020
30 tasks
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.

LGTM. Probably worth a simple yml test for the field caps too.

@javanna
Copy link
Member Author

javanna commented Jul 17, 2020

Probably worth a simple yml test for the field caps too.

I already have a single node integration test, I am not sure that a yaml test adds value at this point. Field caps is already tested separately and we only want to make sure that its output is the same for a runtime field compared to an ordinary field. I can imagine that we may want to revisit this once we change the response format of field caps for runtime fields.

@javanna
Copy link
Member Author

javanna commented Jul 17, 2020

run elasticsearch-ci/packaging-sample-windows

@Override
public ScriptBinaryFieldData.Builder fielddataBuilder(String fullyQualifiedIndexName) {
assert fullyQualifiedIndexName.length() > 0 : "index name must not be empty";
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that I will remove this assertion. I initially assumed that calling this would make us load doc_values for a runtime field which is expensive, but it will only make us instantiate the classes and doc_values will not be advanced, hence no script is going to be executed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

StringScriptFieldScript.Factory factory = scriptCompiler.compile(script.getValue(), StringScriptFieldScript.CONTEXT);
mappedFieldType = new RuntimeKeywordMappedFieldType(buildFullName(context), script.getValue(), factory, meta.getValue());
} else {
BiFunction<Builder, BuilderContext, MappedFieldType> fieldTypeResolver = Builder.FIELD_TYPE_RESOLVER.get(
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nik9000 you may have opinions on this. I added it because I did not want to have tests to maintain a list of supported runtime types and rather rely on the truth which cannot get outdated. Downside is we have no if but rather a map with a bifunction, maybe a bit cryptic.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty used to maps to functions at this point. I'm happy with this. I'm not 100% this is better than the switch statement that I had in #59721, but it does the job just as well. If you like it, I'm happy with it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it does not do a better job than the switch, but it allows to expose all the keys for testing :)

@javanna javanna merged commit 390fa65 into elastic:feature/runtime_fields Jul 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Search/Search Search-related issues that do not fall into other categories Team:Search Meta label for search team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants