Docs: Fixed heading level for in query DSL docs
This commit is contained in:
parent
a522ddb4ac
commit
f85a17ff1a
|
@ -89,11 +89,9 @@ query. The parameter `boost_mode` defines how:
|
|||
By default, modifying the score does not change which documents match. To exclude
|
||||
documents that do not meet a certain score threshold the `min_score` parameter can be set to the desired score threshold.
|
||||
|
||||
==== Score functions
|
||||
|
||||
The `function_score` query provides several types of score functions.
|
||||
|
||||
====== Script score
|
||||
==== Script score
|
||||
|
||||
The `script_score` function allows you to wrap another query and customize
|
||||
the scoring of it optionally with a computation derived from other numeric
|
||||
|
@ -133,7 +131,7 @@ Note that unlike the `custom_score` query, the
|
|||
score of the query is multiplied with the result of the script scoring. If
|
||||
you wish to inhibit this, set `"boost_mode": "replace"`
|
||||
|
||||
====== Weight
|
||||
==== Weight
|
||||
|
||||
The `weight` score allows you to multiply the score by the provided
|
||||
`weight`. This can sometimes be desired since boost value set on
|
||||
|
@ -145,7 +143,7 @@ not.
|
|||
"weight" : number
|
||||
--------------------------------------------------
|
||||
|
||||
====== Random
|
||||
==== Random
|
||||
|
||||
The `random_score` generates scores using a hash of the `_uid` field,
|
||||
with a `seed` for variation. If `seed` is not specified, the current
|
||||
|
@ -161,7 +159,7 @@ be a memory intensive operation since the values are unique.
|
|||
}
|
||||
--------------------------------------------------
|
||||
|
||||
====== Field Value factor
|
||||
==== Field Value factor
|
||||
|
||||
The `field_value_factor` function allows you to use a field from a document to
|
||||
influence the score. It's similar to using the `script_score` function, however,
|
||||
|
@ -205,7 +203,7 @@ is an illegal operation, and an exception will be thrown. Be sure to limit the
|
|||
values of the field with a range filter to avoid this, or use `log1p` and
|
||||
`ln1p`.
|
||||
|
||||
====== Decay functions
|
||||
==== Decay functions
|
||||
|
||||
Decay functions score a document with a function that decays depending
|
||||
on the distance of a numeric field value of the document from a user
|
||||
|
@ -332,7 +330,7 @@ For single functions the three decay functions together with their parameters ca
|
|||
|
||||
image:images/decay_2d.png[width=600]
|
||||
|
||||
====== Multiple values:
|
||||
===== Multiple values:
|
||||
|
||||
If a field used for computing the decay contains multiple values, per default the value closest to the origin is chosen for determining the distance.
|
||||
This can be changed by setting `multi_value_mode`.
|
||||
|
@ -448,7 +446,7 @@ curl 'localhost:9200/hotels/_search/' -d '{
|
|||
Next, we show how the computed score looks like for each of the three
|
||||
possible decay functions.
|
||||
|
||||
====== Normal decay, keyword `gauss`
|
||||
===== Normal decay, keyword `gauss`
|
||||
|
||||
When choosing `gauss` as the decay function in the above example, the
|
||||
contour and surface plot of the multiplier looks like this:
|
||||
|
@ -469,7 +467,7 @@ of 0.56. "BnB Bellevue" and "Backback Nap" are both pretty close to the
|
|||
defined location but "BnB Bellevue" is cheaper, so it gets a multiplier
|
||||
of 0.86 whereas "Backpack Nap" gets a value of 0.66.
|
||||
|
||||
====== Exponential decay, keyword `exp`
|
||||
===== Exponential decay, keyword `exp`
|
||||
|
||||
When choosing `exp` as the decay function in the above example, the
|
||||
contour and surface plot of the multiplier looks like this:
|
||||
|
@ -478,7 +476,7 @@ image::https://f.cloud.github.com/assets/4320215/768161/082975c0-e899-11e2-86f7-
|
|||
|
||||
image::https://f.cloud.github.com/assets/4320215/768162/0b606884-e899-11e2-907b-aefc77eefef6.png[width="700px"]
|
||||
|
||||
====== Linear' decay, keyword `linear`
|
||||
===== Linear decay, keyword `linear`
|
||||
|
||||
When choosing `linear` as the decay function in the above example, the
|
||||
contour and surface plot of the multiplier looks like this:
|
||||
|
@ -487,12 +485,12 @@ image::https://f.cloud.github.com/assets/4320215/768164/1775b0ca-e899-11e2-9f4a-
|
|||
|
||||
image::https://f.cloud.github.com/assets/4320215/768165/19d8b1aa-e899-11e2-91bc-6b0553e8d722.png[width="700px"]
|
||||
|
||||
===== Supported fields for decay functions
|
||||
==== Supported fields for decay functions
|
||||
|
||||
Only single valued numeric fields, including time and geo locations,
|
||||
are supported.
|
||||
|
||||
===== What if a field is missing?
|
||||
==== What if a field is missing?
|
||||
|
||||
If the numeric field is missing in the document, the function will
|
||||
return 1.
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
[[query-dsl-geo-shape-query]]
|
||||
=== GeoShape Filter
|
||||
=== GeoShape Query
|
||||
|
||||
Filter documents indexed using the `geo_shape` type.
|
||||
|
||||
|
@ -10,14 +10,12 @@ geo_shape mapping to find documents that have a shape that intersects
|
|||
with the query shape. It will also use the same PrefixTree configuration
|
||||
as defined for the field mapping.
|
||||
|
||||
==== Filter Format
|
||||
|
||||
The Filter supports two ways of defining the Filter shape, either by
|
||||
The query supports two ways of defining the query shape, either by
|
||||
providing a whole shape definition, or by referencing the name of a shape
|
||||
pre-indexed in another index. Both formats are defined below with
|
||||
examples.
|
||||
|
||||
====== Provided Shape Definition
|
||||
==== Inline Shape Definition
|
||||
|
||||
Similar to the `geo_shape` type, the `geo_shape` Filter uses
|
||||
http://www.geojson.org[GeoJSON] to represent shapes.
|
||||
|
@ -61,7 +59,7 @@ The following query will find the point using the Elasticsearch's
|
|||
}
|
||||
--------------------------------------------------
|
||||
|
||||
===== Pre-Indexed Shape
|
||||
==== Pre-Indexed Shape
|
||||
|
||||
The Filter also supports using a shape which has already been indexed in
|
||||
another index and/or index type. This is particularly useful for when
|
||||
|
|
|
@ -38,7 +38,7 @@ data-type mismatches, such as trying to query a numeric field with a text
|
|||
query string. Defaults to `false`.
|
||||
|
||||
[[query-dsl-match-query-fuzziness]]
|
||||
====== Fuzziness
|
||||
===== Fuzziness
|
||||
|
||||
`fuzziness` allows _fuzzy matching_ based on the type of field being queried.
|
||||
See <<fuzziness>> for allowed settings.
|
||||
|
|
|
@ -200,7 +200,7 @@ For string `"abcd"`:
|
|||
|
||||
--
|
||||
|
||||
====== Optional operators
|
||||
===== Optional operators
|
||||
|
||||
These operators are available by default as the `flags` parameter defaults to `ALL`.
|
||||
Different flag combinations (concatened with `"\"`) can be used to enable/disable
|
||||
|
|
Loading…
Reference in New Issue