-
Notifications
You must be signed in to change notification settings - Fork 25.1k
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
Exclude unmapped fields during max clause limit checking for querying #49523
Conversation
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.
Thanks for your contribution @zacharymorn . I left some comments that need to be addressed. The pr could also be simplified to ignore unmapped fields completely rather than keeping the count in a separate Set
(see review comment).
@@ -143,6 +152,7 @@ private QueryParserHelper() {} | |||
if (fieldType == null) { | |||
// Note that we don't ignore unmapped fields. | |||
fields.put(fieldName, weight); | |||
unmappedFields.add(fieldName); |
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 can ignore unmapped fields here and change the comment ? That's the scope of #49002, we want to ignore unmapped fields so we don't need to forward them to the Lucene parsing.
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.
Got it. I thought previously they may still be needed down the pipe. I've updated the PR per your suggestion.
@@ -1,3 +1,2 @@ | |||
|
|||
yaml.config.exists: 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.
can you revert this change
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.
Ah missed this, removed.
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 seems that it's still there ? ;)
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.
Hmm that's strange, might be my IDE setup problem. Anyway I checked out and committed the previous version of this file before my changes, and I don't see this change in Files Changed
tab anymore. so it should be good now.
@@ -212,21 +212,14 @@ public static void afterClass() throws Exception { | |||
|
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.
Changes on this file are not needed. Can you revert ?
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.
Sorry I forgot to add a comment for this. The changes here are because in two of the new test cases I added, the state of shardContext.mapperService
was changed to force the condition, which affected other test cases as well. By re-creating serviceHolder
for every test case, side effects from test case does not affect another.
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.
Why is it not possible to add your extra fields in QueryStringQueryBuilderTests#initializeAdditionalMappings
? That's where we expect tests to modify the shared mapping. Can you show the test failures if that doesn't work ?
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 did look at that method before. I think the problem of adding additional fields in QueryStringQueryBuilderTests#initializeAdditionalMappings
was that it is adding additional mappings for ALL test cases in that class (the additional xContent mapping is hard coded in the method, which is an override one as well so I can't change its interface to take in additional parameter easily), so that may cause other test cases in that class to also fail.
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.
Sorry for the delay. I tried to modify QueryStringQueryBuilderTests#initializeAdditionalMappings
like the following:
@Override
protected void initializeAdditionalMappings(MapperService mapperService) throws IOException {
XContentBuilder mapping = jsonBuilder().startObject().startObject("_doc").startObject("properties")
.startObject("prefix_field")
.field("type", "text")
.startObject("index_prefixes").endObject()
.endObject()
.startObject("additionalMappedField1")
.field("type", "text")
.endObject()
.startObject("additionalMappedField2")
.field("type", "text")
.endObject()
.startObject("additionalMappedField3")
.field("type", "text")
.endObject()
.startObject("additionalMappedField4")
.field("type", "text")
.endObject()
.endObject().endObject().endObject();
mapperService.merge("_doc",
new CompressedXContent(Strings.toString(mapping)), MapperService.MergeReason.MAPPING_UPDATE);
}
and all tests worked without modification. Could you try so that we can remove this unneeded change ?
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.
Yes sorry I checked without the modified indices.query.bool.max_clause_count
. It seems tricky to test this behavior here so maybe you can modify or add a new test similar to
elasticsearch/server/src/test/java/org/elasticsearch/search/query/QueryStringIT.java
Line 266 in a59b065
public void testLimitOnExpandedFields() throws Exception { |
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.
Didn’t realize there’s an integration test for this as well…I just added a new test there.
I also removed this line of Index setting
elasticsearch/server/src/test/java/org/elasticsearch/search/query/QueryStringIT.java
Lines 279 to 280 in a59b065
.setSettings(Settings.builder().put(MapperService.INDEX_MAPPING_TOTAL_FIELDS_LIMIT_SETTING.getKey(), | |
CLUSTER_MAX_CLAUSE_COUNT + 100)) |
QueryStringIT.testLimitOnExpandedFields
as it doesn’t seems to make sense in the context (why is it setting INDEX_MAPPING_TOTAL_FIELDS_LIMIT_SETTING to CLUSTER_MAX_CLAUSE_COUNT + 100?), and have no impact to test result. But please let me know if that’s indeed needed and I can put it back.
Having added the additional test though, I feel this test and the ones I’ve already put in and passing are different levels of tests (integration & unit tests) and thus it doesn’t hurt for them to coexist. Are you suggesting to have integration test only for these changes?
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.
Are you suggesting to have integration test only for these changes?
Yes, mainly because it seems challenging to have a simple unit test for this and we already have integration tests.
In test QueryStringIT.testLimitOnExpandedFields as it doesn’t seems to make sense in the context (why is it setting INDEX_MAPPING_TOTAL_FIELDS_LIMIT_SETTING to CLUSTER_MAX_CLAUSE_COUNT + 100?), and have no impact to test result. But please let me know if that’s indeed needed and I can put it back.
I don't think it's needed either but that's unrelated to this pr so not sure if we should remove it now ?
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 just pushed another commit that reverted the unneeded change to the integration test, and the unit tests and their related changes.
However, I guess I’m still a bit confused for why it’s tricky to keep those unit tests there, when they are already passing and verifying the right logic. As can be seen in the new (reverting) commit, the changes I made to allow unit tests there are the following:
- The new unit tests themselves
- Local, test class level change to force the condition for the added unit tests (setting
indices.query.bool.max_clause_count
) - Super test class level change to make sure that each tests are independent to each other so that Discovery: Support local (JVM level) discovery #2 doesn’t break other test cases (the changes in
AbstractBuilderTestCase.beforeTest
)
These changes combined would allow the newly added test cases to pass, and not break any existing test cases.
I feel I’m still having some gap in understanding the reasoning here, but I’ll leave it to you. Thanks for your patience and time for reviewing my changes!
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 feel I’m still having some gap in understanding the reasoning here, but I’ll leave it to you
My reasoning here is that the abstract class for these tests was designed to share the mapping within the tests so it would require a bigger refactoring to change this behavior. We also have a lot of unit tests here so even if they pass I am cautious of the additional work that would be needed if we switch to one configuration per test.
server/src/test/java/org/elasticsearch/index/query/QueryStringQueryBuilderTests.java
Outdated
Show resolved
Hide resolved
server/src/test/java/org/elasticsearch/index/query/QueryStringQueryBuilderTests.java
Outdated
Show resolved
Hide resolved
Pinging @elastic/es-search (:Search/Search) |
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.
Thanks @zacharymorn , I left more comments
@@ -212,21 +212,14 @@ public static void afterClass() throws Exception { | |||
|
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.
Why is it not possible to add your extra fields in QueryStringQueryBuilderTests#initializeAdditionalMappings
? That's where we expect tests to modify the shared mapping. Can you show the test failures if that doesn't work ?
@@ -1,3 +1,2 @@ | |||
|
|||
yaml.config.exists: 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 seems that it's still there ? ;)
@elasticmachine ok to test. |
@elasticmachine update branch |
builder.endObject(); // type1 | ||
builder.endObject(); | ||
|
||
assertAcked(prepareCreate("ignoreunmappedfields").addMapping("type1", builder)); |
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.
@zacharymorn I merged master in your pr and now there's a test compilation error. Can you take a look ?
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 merged master in and looks like there’s change in CreateIndexRequestBuilder.addMapping
. Just updated the test and pushed up the commits. The CI is still failing though it was broken for an seemingly unrelated integration test org.elasticsearch.snapshots.DedicatedClusterSnapshotRestoreIT.testMasterShutdownDuringSnapshot
. Is this something I should be looking into as well ?
@elasticmachine test elasticsearch-ci/1 |
@elasticmachine ok to test |
@elasticmachine update branch |
Thanks @zacharymorn |
Take into account of number of unmapped fields when calculating against limit. Closes #49002
Take into account of number of unmapped fields when calculating against limit. Closes elastic#49002
Take into account of number of unmapped fields when calculating against limit. For details, please see #49002