-
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
Make Geo Context Parsing More Strict #32412
Changes from 2 commits
12e689b
26b927e
0a14711
ce83aac
097d93d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -19,7 +19,8 @@ | |
|
||
package org.elasticsearch.search.suggest.completion.context; | ||
|
||
import org.apache.lucene.document.StringField; | ||
import org.apache.lucene.document.LatLonDocValuesField; | ||
import org.apache.lucene.document.LatLonPoint; | ||
import org.apache.lucene.index.DocValuesType; | ||
import org.apache.lucene.index.IndexableField; | ||
import org.elasticsearch.ElasticsearchParseException; | ||
|
@@ -200,18 +201,29 @@ public Set<CharSequence> parseContext(Document document) { | |
geohashes.add(stringEncode(spare.getLon(), spare.getLat(), precision)); | ||
} | ||
} | ||
} else { | ||
// Does this object exist? If it does and we didn't find what we need - we need to warn user | ||
for (IndexableField field : document.getFields()) { | ||
if (field.name().startsWith(fieldName + ".")) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I know the "dots in field names" discussion has been a long running one. Do we not yet have a more general/graceful way of throwing these exceptions? This is more of a question out of my own curiosity and not intended to hold up the PR. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am not sure we should do that, can we restrict the geo context to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can definitely remove that and clean this up even more, but this will be much more breaking change, since today you can have this sudo geo object and it works, if we will remove this in 7, then working indices with this, created in 6 are going to break. I am not sure we can do that. We will probably have to disable it for indices in 7 but I don't think we can fully remove it until 8. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd treat this case like the geohash string version, this is not documented nor tested so we should remove it. The documentation is clear, you can use a path that references a geo_point field or set the point directly in the context. |
||
throw new ElasticsearchParseException( | ||
"cannot parse geo context field [{}], expected object with lat/lon fields or geo_point", fieldName); | ||
} | ||
} | ||
} | ||
} else { | ||
for (IndexableField field : fields) { | ||
if (field instanceof StringField) { | ||
spare.resetFromString(field.stringValue()); | ||
} else { | ||
if (field instanceof LatLonPoint || field instanceof LatLonDocValuesField){ | ||
// todo return this to .stringValue() once LatLonPoint implements it | ||
spare.resetFromIndexableField(field); | ||
geohashes.add(spare.geohash()); | ||
} | ||
geohashes.add(spare.geohash()); | ||
} | ||
if (geohashes.isEmpty()) { | ||
throw new ElasticsearchParseException( | ||
"cannot parse geo context field [{}], expected object with lat/lon fields or geo_point", fieldName); | ||
} | ||
} | ||
|
||
} | ||
|
||
Set<CharSequence> locations = new HashSet<>(); | ||
|
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.
the code above seems useless in 7 (even in 6.x ?) since we have a
LatLonPoint
and aLatLonDocValuesField
?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.
The way I understood the code above is if you want to represent lat and lon as an object, but don't want to index it as an actual geopoint you could do that.