-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
Add tests for the supported query types. #35319
Add tests for the supported query types. #35319
Conversation
Pinging @elastic/es-search-aggs |
boolean includeLower, | ||
boolean includeUpper, | ||
QueryShardContext context) { | ||
if (lowerTerm == null || upperTerm == null) { |
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 could fix this instead of disallowing unbounded range queries, but I wasn't sure the extra complexity was worth it. It's not clear how useful this range functionality will be right now, especially without support for numerics.
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 like this limitation is ok for now. We can revisit this later if necessary
909c276
to
f693e46
Compare
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 left a comment but otherwise I think this is good. I'd like @romseygeek to take a look too though
boolean includeLower, | ||
boolean includeUpper, | ||
QueryShardContext context) { | ||
if (lowerTerm == null || upperTerm == null) { |
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 like this limitation is ok for now. We can revisit this later if necessary
TermRangeQuery expected = new TermRangeQuery("field", | ||
new BytesRef("key\0lower"), | ||
new BytesRef("key\0upper"), false, false); | ||
assertEquals(expected, ft.rangeQuery("lower", "upper", false, false, null)); |
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.
should we also check that we do the right thing if the bounds are inclusive?
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.
👍
e4ee31c
to
2ffb459
Compare
f693e46
to
956a75d
Compare
.startObject() | ||
.startObject("headers") | ||
.field("content-type", "application/json") | ||
.endObject() |
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.
Not especially related to the current PR, but how is case normalization being handled? The normal HTTP header here is Content-type
with a capital C; is there a lowercase filter being applied anywhere, or is that being ignored for the moment?
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 don't apply any lowercasing to the object keys. This is consistent with the way normal field names are handled in the mapping, which are not lowercased (you could have two distinct fields for example, one named Content-Type
and the other content-type
). Do you think an option to automatically case-fold the keys would be useful?
Separately for field values (not keys), keyword
fields provide a normalizer
option. This is something we could consider, although it might need to be designed differently as json
fields can contain non-string values.
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.
LGTM. I have one completely unrelated comment to do with case normalization, but feel free to answer that elsewhere...
Thank you both for reviewing, I plan to fix the failing test and merge. |
cb19e81
to
7a3c18e
Compare
This affects some of the checks in tests, but doesn't have an actual effect on indexing (because there we rely on FieldType#docValuesType).
* Add tests for the supported query types. * Disallow unbounded range queries on keyed JSON fields. * Make sure MappedFieldType#hasDocValues always returns false.
* Add tests for the supported query types. * Disallow unbounded range queries on keyed JSON fields. * Make sure MappedFieldType#hasDocValues always returns false.
* Add tests for the supported query types. * Disallow unbounded range queries on keyed JSON fields. * Make sure MappedFieldType#hasDocValues always returns false.
* Add tests for the supported query types. * Disallow unbounded range queries on keyed JSON fields. * Make sure MappedFieldType#hasDocValues always returns false.
* Add tests for the supported query types. * Disallow unbounded range queries on keyed JSON fields. * Make sure MappedFieldType#hasDocValues always returns false.
* Add tests for the supported query types. * Disallow unbounded range queries on keyed JSON fields. * Make sure MappedFieldType#hasDocValues always returns false.
* Add tests for the supported query types. * Disallow unbounded range queries on keyed JSON fields. * Make sure MappedFieldType#hasDocValues always returns false.
* Add tests for the supported query types. * Disallow unbounded range queries on keyed JSON fields. * Make sure MappedFieldType#hasDocValues always returns false.
* Add tests for the supported query types. * Disallow unbounded range queries on keyed JSON fields. * Make sure MappedFieldType#hasDocValues always returns false.
* Add tests for the supported query types. * Disallow unbounded range queries on keyed JSON fields. * Make sure MappedFieldType#hasDocValues always returns false.
* Add tests for the supported query types. * Disallow unbounded range queries on keyed JSON fields. * Make sure MappedFieldType#hasDocValues always returns false.
* Add tests for the supported query types. * Disallow unbounded range queries on keyed JSON fields. * Make sure MappedFieldType#hasDocValues always returns false.
* Add tests for the supported query types. * Disallow unbounded range queries on keyed JSON fields. * Make sure MappedFieldType#hasDocValues always returns false.
* Add tests for the supported query types. * Disallow unbounded range queries on keyed JSON fields. * Make sure MappedFieldType#hasDocValues always returns false.
* Add tests for the supported query types. * Disallow unbounded range queries on keyed JSON fields. * Make sure MappedFieldType#hasDocValues always returns false.
* Add tests for the supported query types. * Disallow unbounded range queries on keyed JSON fields. * Make sure MappedFieldType#hasDocValues always returns false.
* Add tests for the supported query types. * Disallow unbounded range queries on keyed JSON fields. * Make sure MappedFieldType#hasDocValues always returns false.
* Add tests for the supported query types. * Disallow unbounded range queries on keyed JSON fields. * Make sure MappedFieldType#hasDocValues always returns false.
The following query types should now be covered:
term
,terms
andterms_set
prefix
range
match
andmulti_match
query_string
andsimple_query_string
exists
I preferred unit tests as much as possible, but certain query types (like
match
andquery_string
) were more natural to check through integration tests.