Skip to content

Conversation

@costin
Copy link
Member

@costin costin commented Apr 19, 2019

Thanks to #34071, there is enough information in field caps to infer
the table structure and thus use the same API consistently across the
IndexResolver.

Thanks to elastic#34071, there is enough information in field caps to infer
the table structure and thus use the same API consistently across the
IndexResolver.
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search

@costin costin closed this Apr 21, 2019
@costin costin deleted the field_caps_migration_2 branch April 21, 2019 18:09
@costin costin restored the field_caps_migration_2 branch April 22, 2019 08:17
@costin costin reopened this Apr 22, 2019
Copy link
Contributor

@astefan astefan left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@matriv matriv left a comment

Choose a reason for hiding this comment

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

LGTM. Left some minor comments.

String name = entry.getKey();
for (Entry<String, FieldCapabilities> type : types.entrySet()) {
// skip unmapped
if (UNMAPPED.equals(type.getKey())) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Personal preference: I'd inverse the check and surround the whole block with this if, rather than use continue

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'm not a fan of continue but I prefer it instead of indenting a long method already wrapped...

Copy link
Contributor

Choose a reason for hiding this comment

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

Yep, I understand, and I'm not insisting, I didn't comment at all here: https://github.com/elastic/elasticsearch/pull/41377/files/2e890c11f3283d32c6325f7d9ebb7d14b1972ec5#diff-e9f288c0280d1beafe4dc4cf86c12c7bR433 where the block is even larger as inverting the if makes it much less readable.

return esField;
}

Copy link
Contributor

Choose a reason for hiding this comment

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

unnecessary whitespaces

// make a copy of the list to be able to modify it
concreteIndices = new ArrayList<>(asList(capIndices));
if (unmappedIndices.isEmpty() == false) {
concreteIndices.removeAll(unmappedIndices);
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe not so important: I would use a Set for the unmappedIndices and use contains() to speed up the removal. This way you can iterate on the String[] and create the concreteIndices list.

@costin costin force-pushed the field_caps_migration_2 branch from 7277e9c to 1853ac3 Compare April 22, 2019 15:09
@costin costin merged commit f999469 into elastic:master Apr 22, 2019
@costin costin deleted the field_caps_migration_2 branch April 22, 2019 19:41
costin added a commit that referenced this pull request Apr 25, 2019
Thanks to #34071, there is enough information in field caps to infer
the table structure and thus use the same API consistently across the
IndexResolver.

(cherry picked from commit f999469)
gurkankaymak pushed a commit to gurkankaymak/elasticsearch that referenced this pull request May 27, 2019
Thanks to elastic#34071, there is enough information in field caps to infer
the table structure and thus use the same API consistently across the
IndexResolver.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants