mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-07 21:48:39 +00:00
1e587406d8
Adds `warnings` syntax to the yaml test that allows you to expect
a `Warning` header that looks like:
```
- do:
warnings:
- '[index] is deprecated'
- quotes are not required because yaml
- but this argument is always a list, never a single string
- no matter how many warnings you expect
get:
index: test
type: test
id: 1
```
These are accessible from the docs with:
```
// TEST[warning:some warning]
```
This should help to force you to update the docs if you deprecate
something. You *must* add the warnings marker to the docs or the build
will fail. While you are there you *should* update the docs to add
deprecation warnings visible in the rendered results.
73 lines
2.0 KiB
Plaintext
73 lines
2.0 KiB
Plaintext
[[lat-lon]]
|
|
=== `lat_lon`
|
|
|
|
deprecated[5.0.0, ????????]
|
|
// https://github.com/elastic/elasticsearch/issues/19792
|
|
|
|
<<geo-queries,Geo-queries>> are usually performed by plugging the value of
|
|
each <<geo-point,`geo_point`>> field into a formula to determine whether it
|
|
falls into the required area or not. Unlike most queries, the inverted index
|
|
is not involved.
|
|
|
|
Setting `lat_lon` to `true` causes the latitude and longitude values to be
|
|
indexed as numeric fields (called `.lat` and `.lon`). These fields can be used
|
|
by the <<query-dsl-geo-bounding-box-query,`geo_bounding_box`>> and
|
|
<<query-dsl-geo-distance-query,`geo_distance`>> queries instead of
|
|
performing in-memory calculations. So this mapping:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
PUT my_index
|
|
{
|
|
"mappings": {
|
|
"my_type": {
|
|
"properties": {
|
|
"location": {
|
|
"type": "geo_point",
|
|
"lat_lon": true <1>
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// TEST[warning:geo_point lat_lon parameter is deprecated and will be removed in the next major release]
|
|
<1> Setting `lat_lon` to true indexes the geo-point in the `location.lat` and `location.lon` fields.
|
|
|
|
Allows these actions:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
PUT my_index/my_type/1?refresh
|
|
{
|
|
"location": {
|
|
"lat": 41.12,
|
|
"lon": -71.34
|
|
}
|
|
}
|
|
|
|
|
|
GET my_index/_search
|
|
{
|
|
"query": {
|
|
"geo_distance": {
|
|
"location": {
|
|
"lat": 41,
|
|
"lon": -71
|
|
},
|
|
"distance": "50km",
|
|
"optimize_bbox": "indexed" <1>
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[continued]
|
|
<1> The `indexed` option tells the geo-distance query to use the inverted index instead of the in-memory calculation.
|
|
|
|
Whether the in-memory or indexed operation performs better depends both on
|
|
your dataset and on the types of queries that you are running.
|
|
|
|
NOTE: The `lat_lon` option only makes sense for single-value `geo_point`
|
|
fields. It will not work with arrays of geo-points.
|