mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-05 20:48:22 +00:00
25aac4f77f
The "include_type_name" parameter was temporarily introduced in #37285 to facilitate moving the default parameter setting to "false" in many places in the documentation code snippets. Most of the places can simply be reverted without causing errors. In this change I looked for asciidoc files that contained the "include_type_name=true" addition when creating new indices but didn't look likey they made use of the "_doc" type for mappings. This is mostly the case e.g. in the analysis docs where index creating often only contains settings. I manually corrected the use of types in some places where the docs still used an explicit type name and not the dummy "_doc" type.
89 lines
2.0 KiB
Plaintext
89 lines
2.0 KiB
Plaintext
[[analysis-keyword-analyzer]]
|
|
=== Keyword Analyzer
|
|
|
|
The `keyword` analyzer is a ``noop'' analyzer which returns the entire input
|
|
string as a single token.
|
|
|
|
[float]
|
|
=== Example output
|
|
|
|
[source,js]
|
|
---------------------------
|
|
POST _analyze
|
|
{
|
|
"analyzer": "keyword",
|
|
"text": "The 2 QUICK Brown-Foxes jumped over the lazy dog's bone."
|
|
}
|
|
---------------------------
|
|
// CONSOLE
|
|
|
|
/////////////////////
|
|
|
|
[source,js]
|
|
----------------------------
|
|
{
|
|
"tokens": [
|
|
{
|
|
"token": "The 2 QUICK Brown-Foxes jumped over the lazy dog's bone.",
|
|
"start_offset": 0,
|
|
"end_offset": 56,
|
|
"type": "word",
|
|
"position": 0
|
|
}
|
|
]
|
|
}
|
|
----------------------------
|
|
// TESTRESPONSE
|
|
|
|
/////////////////////
|
|
|
|
|
|
The above sentence would produce the following single term:
|
|
|
|
[source,text]
|
|
---------------------------
|
|
[ The 2 QUICK Brown-Foxes jumped over the lazy dog's bone. ]
|
|
---------------------------
|
|
|
|
[float]
|
|
=== Configuration
|
|
|
|
The `keyword` analyzer is not configurable.
|
|
|
|
[float]
|
|
=== Definition
|
|
|
|
The `keyword` analyzer consists of:
|
|
|
|
Tokenizer::
|
|
* <<analysis-keyword-tokenizer,Keyword Tokenizer>>
|
|
|
|
If you need to customize the `keyword` analyzer then you need to
|
|
recreate it as a `custom` analyzer and modify it, usually by adding
|
|
token filters. Usually, you should prefer the
|
|
<<keyword, Keyword type>> when you want strings that are not split
|
|
into tokens, but just in case you need it, this would recreate the
|
|
built-in `keyword` analyzer and you can use it as a starting point
|
|
for further customization:
|
|
|
|
[source,js]
|
|
----------------------------------------------------
|
|
PUT /keyword_example
|
|
{
|
|
"settings": {
|
|
"analysis": {
|
|
"analyzer": {
|
|
"rebuilt_keyword": {
|
|
"tokenizer": "keyword",
|
|
"filter": [ <1>
|
|
]
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
----------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[s/\n$/\nstartyaml\n - compare_analyzers: {index: keyword_example, first: keyword, second: rebuilt_keyword}\nendyaml\n/]
|
|
<1> You'd add any token filters here.
|