-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Queries and unmapped fields #12016
Comments
Maybe we should then also have a FieldNotFound agg to have similar behaviour for aggs too? |
From a migration standpoint its always better to return no results than to blow up. I often deploy code that relies on the "if the field isn't there then nothing happens" behavior and create the field over time. Its just more sane that way. So I'm +1 on that. Last I checked the term and phrase suggester return exceptions if the field doesn't exist and it'd be nicer if they didn't. Not critical. Just nicer. |
Having a "field not found" query seems very odd (just the name). What about returning a MatchNoDocsQuery, but extending that to have a message about why match no docs was chosen (essentially giving a reason, since match no docs alone doesn't make any sense when building a real query)? |
@rjernst makes sense |
This add equals, hashcode, read/write methods, validation, separates toQuery and JSON parsing and adds serialization and query generation tests. Deprecates two types of initializing the bounding box: In our documentation we speak about specifying top/left and bottom/right corner of a bounding box. Here we also allow for top/right and bottom/left. This adds not only to the amount of code but also testing needed w/o too much benefit for the user other than more chances to confuse top/right/bottom/left/latitude/longitude IMHO. Missing: The toQuery method with type set to "indexed" is not tested at the moment. Cleanup changes unrelated to base refactoring: * Switched from type String to enum for types in GeoBoundingBoxQueryBuilder. * Switched to using type GeoPoint for storing the bounding box coordinates instead of array of double values. Relates to elastic#10217 for the query refactoring part. Relates to elastic#12016 for how missing mappings are handled. Adds a utility class for generating random geo data. Adds some missing documentation. Extend test to MEMORY type config
This add equals, hashcode, read/write methods, validation, separates toQuery and JSON parsing and adds serialization and query generation tests. Deprecates two types of initializing the bounding box: In our documentation we speak about specifying top/left and bottom/right corner of a bounding box. Here we also allow for top/right and bottom/left. This adds not only to the amount of code but also testing needed w/o too much benefit for the user other than more chances to confuse top/right/bottom/left/latitude/longitude IMHO. Missing: The toQuery method with type set to "indexed" is not tested at the moment. Cleanup changes unrelated to base refactoring: * Switched from type String to enum for types in GeoBoundingBoxQueryBuilder. * Switched to using type GeoPoint for storing the bounding box coordinates instead of array of double values. Relates to elastic#10217 for the query refactoring part. Relates to elastic#12016 for how missing mappings are handled. Adds a utility class for generating random geo data. Adds some missing documentation. Extend test to MEMORY type config Fix final review comments and rebase
We now have #17748 and #17751 which add an |
How do any of these help with a bool query? Use case is a variant on the 'multiple indices' one: I've recently started indexing a field that is used to exclude results with bool/must_not. This works with 2.4, not with 5.x. I don't see how this could be rewritten as any of the queries that support |
It still does not work with simple terms filter and others. That's a bit sad. Since ES supports queries on multiple indices, we're forced to have exactly same mapping. Are there any other options? |
terms filter already ignore missing fields so this works just fine. perhaps ask a question in the forum instead |
As discussed in #11806, different queries handle unmapped fields differently. The
nested
,has_child
,has_parent
,geo_*
, andfunction_score
query throw exceptions, while all of the others match no docs instead.We need to make the behaviour uniform across queries.
The solution we came up with in FixItFriday is:
FieldNotFound
query, which matches no documentsexplain
is turned on, then thefield_not_found
query will be part of the outputstrict_mappings
is passed, then the request will throw a field not found exception instead.This preserves the ease of use of, eg:
without making search requests even more verbose, but makes debugging bad field names easy.
The text was updated successfully, but these errors were encountered: