geo_point runtime field implementation#63164
Conversation
|
Pinging @elastic/es-analytics-geo (:Analytics/Geo) |
|
Pinging @elastic/es-search (:Search/Search) |
...st/java/org/elasticsearch/xpack/runtimefields/mapper/GeoPointScriptMappedFieldTypeTests.java
Outdated
Show resolved
Hide resolved
|
@elasticmachine run elasticsearch-ci/packaging-sample-windows |
|
@elasticmachine run elasticsearch-ci/1 |
nik9000
left a comment
There was a problem hiding this comment.
I took a look and it looks pretty reasonable.
...plugin/runtime-fields/src/main/java/org/elasticsearch/xpack/runtimefields/RuntimeFields.java
Outdated
Show resolved
Hide resolved
| return new GeoPointScriptFieldGeoShapeQuery(script, leafFactory(context), fieldName, geometries); | ||
| } | ||
|
|
||
| private static LatLonGeometry[] toLuceneGeometry(String name, QueryShardContext context, Geometry geometry) { |
There was a problem hiding this comment.
Is this something we can move into core? It looks like something we'd have there already?
There was a problem hiding this comment.
Thats is my plan but it seems more difficult that it looks at first sight as every time we need to map a geometry to a Lucene geometry, it seems to be slightly different. As part of that effort I opened https://issues.apache.org/jira/browse/LUCENE-9552 but I didn't have much support so far. I try to move it.
| return mockContext(allowExpensiveQueries, null); | ||
| } | ||
|
|
||
| protected boolean supportsTermQueries() { |
There was a problem hiding this comment.
Maybe it'd be better to make a new superclass that doesn't have these methods?
There was a problem hiding this comment.
The problem is that we already have AbstractNonTextScriptFieldTypeTestCase that extends this class. Those methods are worthy running so adding a superclass you will miss that. My feeling is that we need an abstract class for every type of query and field types will implement all the ones they support?
There was a problem hiding this comment.
So instead of an abstract superclass for the type of field it is per query? I could see that being better, maybe. I'm ok with this as is if we plan to refactor it soon enough anyway.
|
@elasticmachine run elasticsearch-ci/packaging-sample-windows |
nik9000
left a comment
There was a problem hiding this comment.
This looks entirely sensible to me.
x-pack/plugin/src/test/resources/rest-api-spec/test/runtime_fields/100_geo_point.yml
Outdated
Show resolved
Hide resolved
|
Moved the PR to ready for review (although thanks Nik, you've done all the work already). |
nik9000
left a comment
There was a problem hiding this comment.
I'm happy with it! I feel like I should find something worth changing because runtime fields are new and we don't have super established patterns, but I think this is the right things to do.
Run time field that emits geo points from lat/lon values.
Run time field that emits geo points from lat/lon values.
Run time field that emits geo points from lat/lon values. For example, given a mapping like:
A geo_point runtime field can be declared as:
where the emit function takes two arguments, the first argument is the latitude and the second argument the longitude.