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

Make FieldNamesFieldMapper responsible for adding its own doc fields #71929

Merged
merged 5 commits into from
Apr 27, 2021

Conversation

romseygeek
Copy link
Contributor

@romseygeek romseygeek commented Apr 20, 2021

The FieldNamesFieldMapper is a metadata mapper defining a field that
can be used for exists queries if a mapper does not use doc values or
norms. Currently, data is added to it via a special method on FieldMapper
that pulls the metadata mapper from a mapping lookup, checks to see
if it is enabled, and then adds the relevant value to a lucene document.

This is one of only two places that pulls a metadata mapper from the
MappingLookup, and it would be nice to remove this method. This commit
refactors field name handling by instead storing the names of fields to
index in the fieldnames field in a set on the ParseContext, and then
building the field itself in FieldNamesFieldMapper.postParse(). This means
that all of the responsibility for enabling indexing, etc, is handled within
the metadata mapper itself.

This commit also removes indexing of all parent paths. Previously, given
a field parent.child.grandchild we would index parent, parent.child
and parent.child.grandchild in the field names field, and this was originally
used to allow efficient exists queries on object fields. However, since we
moved to using docvalue iterators for exists fields where possible, exists
queries against object fields have been built differently and so these
extra paths are unused.

@romseygeek romseygeek added :Search Foundations/Mapping Index mappings, including merging and defining field types >refactoring v8.0.0 v7.14.0 labels Apr 20, 2021
@romseygeek romseygeek requested a review from javanna April 20, 2021 12:50
@romseygeek romseygeek self-assigned this Apr 20, 2021
@elasticmachine elasticmachine added the Team:Search Meta label for search team label Apr 20, 2021
@elasticmachine
Copy link
Collaborator

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

Copy link
Member

@javanna javanna left a comment

Choose a reason for hiding this comment

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

left a couple of small comments, LGTM otherwise. Thanks, this is a good cleanup.

@@ -266,19 +264,6 @@ protected void indexScriptValues(SearchLookup searchLookup, LeafReaderContext re
throw new UnsupportedOperationException("FieldMapper " + name() + " does not support [script]");
}

protected final void createFieldNamesField(ParseContext context) {
assert fieldType().hasDocValues() == false : "_field_names should only be used when doc_values are turned off";
Copy link
Member

Choose a reason for hiding this comment

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

is there a way to keep this assertion? I vaguely remember adding it while cleaning up some inconsistencies around using field_names where it would not make sense

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've added an assertion in FieldNamesFieldMapper.postParse()


};
}
};
Copy link
Member

Choose a reason for hiding this comment

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

on simplifying this and not indexing all the inner paths, that makes sense, but should we make that change in a separate PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a good point, I'll pull this change into a separate issue.

@@ -490,6 +501,16 @@ public void addIgnoredField(String field) {
public Collection<String> getIgnoredFields() {
return Collections.unmodifiableCollection(ignoredFields);
}

@Override
public void addFieldExistsField(String field) {
Copy link
Member

Choose a reason for hiding this comment

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

nit: I slightly prefer the previous name, shall we call it addFieldToFieldNames ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I ended up with addtoFieldNames

}

@Override
public Collection<String> getFieldExistsFields() {
Copy link
Member

Choose a reason for hiding this comment

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

getFieldNames?

@romseygeek romseygeek merged commit e002aa8 into elastic:master Apr 27, 2021
@romseygeek romseygeek deleted the mapper/field-names-metafield branch April 27, 2021 15:03
romseygeek added a commit that referenced this pull request Apr 27, 2021
…71929)

The FieldNamesFieldMapper is a metadata mapper defining a field that
can be used for exists queries if a mapper does not use doc values or
norms. Currently, data is added to it via a special method on FieldMapper
that pulls the metadata mapper from a mapping lookup, checks to see
if it is enabled, and then adds the relevant value to a lucene document.

This is one of only two places that pulls a metadata mapper from the
MappingLookup, and it would be nice to remove this method. This commit
refactors field name handling by instead storing the names of fields to
index in the fieldnames field in a set on the ParseContext, and then
building the field itself in FieldNamesFieldMapper.postParse(). This means
that all of the responsibility for enabling indexing, etc, is handled within
the metadata mapper itself.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>refactoring :Search Foundations/Mapping Index mappings, including merging and defining field types Team:Search Meta label for search team v7.14.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants