* Adding a tip to make null field behavior more apparent.
* Update docs/reference/esql/processing-commands/where.asciidoc
Co-authored-by: Andrei Stefan <astefan@users.noreply.github.com>
* Update docs/reference/esql/processing-commands/where.asciidoc
Rephrasing for clarity
Co-authored-by: Liam Thompson <32779855+leemthompo@users.noreply.github.com>
---------
Co-authored-by: Andrei Stefan <astefan@users.noreply.github.com>
Co-authored-by: Liam Thompson <32779855+leemthompo@users.noreply.github.com>
* Add a query rules tester API call
* Update docs/changelog/114168.yaml
* Wrap client call in async with origin
* Remove unused param
* PR feedback
* Remove redundant test
* CI workaround - add ent-search as ml dependency so it can find node features
Special values like `0.0.0.0` may resolve to multiple IP addresses just
like hostnames, so the same considerations apply when using such values
as a publish address. This commit spells this case out in the docs and
cleans up the nearby wording a little.
* Creates a new page for the hybrid search tutorial
* Update docs/reference/search/search-your-data/semantic-text-hybrid-search
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
* Update docs/reference/search/search-your-data/semantic-text-hybrid-search
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
* Update docs/reference/search/search-your-data/semantic-text-hybrid-search
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
* Update docs/reference/search/search-your-data/semantic-text-hybrid-search
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
* Update docs/reference/search/search-your-data/semantic-text-hybrid-search
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
* Update docs/reference/search/search-your-data/semantic-text-hybrid-search
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
* Update docs/reference/search/search-your-data/semantic-text-hybrid-search
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
* Update docs/reference/search/search-your-data/semantic-text-hybrid-search
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
* Update docs/reference/search/search-your-data/semantic-text-hybrid-search
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
* Update docs/reference/search/search-your-data/semantic-text-hybrid-search
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
* Adds search response example
* Update docs/reference/search/search-your-data/semantic-text-hybrid-search
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
* Update docs/reference/search/search-your-data/semantic-text-hybrid-search
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
* Update docs/reference/search/search-your-data/semantic-text-hybrid-search
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
* Update docs/reference/search/search-your-data/semantic-text-hybrid-search
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
* Update docs/reference/search/search-your-data/semantic-text-hybrid-search
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
* Update docs/reference/search/search-your-data/semantic-text-hybrid-search
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
* Update docs/reference/search/search-your-data/semantic-text-hybrid-search
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
* Update docs/reference/search/search-your-data/semantic-text-hybrid-search
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
---------
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
Since Kibana only needs CCS metadata in ESQL responses from certain well-defined locations,
we are making CCS metadata opt-in. This feature is patterned after ESQL profiling, where
you specify "profile": true in the ESQL body and if you asked for it will be present in the response
always (it will be written to the .async-search index and you can’t turn it off in later async-search
requests against this particular query ID) and if you didn’t ask for it at the beginning it will never
be present (it will NOT be written to the .async-search index when it is persisted).
The new option is "include_ccs_metadata": true/false.
A docs page for the `terminate` processor was added in
https://github.com/elastic/elasticsearch/pull/114157, but the change
to include it in the outer processor reference page was omitted. This
change corrects that oversight.
This adds support for a new `index_template_substitutions` field to the
body of an ingest simulate API request. These substitutions can be used
to change the pipeline(s) used for ingest, or to change the mappings
used for validation. It is similar to the
`component_template_substitutions` added in #113276. Here is an example
that shows both of those usages working together:
```
## First, add a couple of pipelines that set a field to a boolean:
PUT /_ingest/pipeline/foo-pipeline?pretty
{
"processors": [
{
"set": {
"field": "foo",
"value": true
}
}
]
}
PUT /_ingest/pipeline/bar-pipeline?pretty
{
"processors": [
{
"set": {
"field": "bar",
"value": true
}
}
]
}
## Now, create three component templates. One provides a mapping enforces that the only field is "foo"
## and that field is a keyword. The next is similar, but adds a `bar` field. The final one provides a setting
## that makes "foo-pipeline" the default pipeline.
## Remember that the "foo-pipeline" sets the "foo" field to a boolean, so using both of these templates
## together would cause a validation exception. These could be in the same template, but are provided
## separately just so that later we can show how multiple templates can be overridden.
PUT _component_template/mappings_template
{
"template": {
"mappings": {
"dynamic": "strict",
"properties": {
"foo": {
"type": "keyword"
}
}
}
}
}
PUT _component_template/mappings_template_with_bar
{
"template": {
"mappings": {
"dynamic": "strict",
"properties": {
"foo": {
"type": "keyword"
},
"bar": {
"type": "boolean"
}
}
}
}
}
PUT _component_template/settings_template
{
"template": {
"settings": {
"index": {
"default_pipeline": "foo-pipeline"
}
}
}
}
## Here we create an index template pulling in both of the component templates above
PUT _index_template/template_1
{
"index_patterns": ["foo*"],
"composed_of": ["mappings_template", "settings_template"]
}
## We can index a document here to create the index, or not. Either way the simulate call ought to work the same
POST foo-1/_doc
{
"foo": "FOO"
}
## This will not blow up with validation exceptions because the substitute "index_template_substitutions"
## uses `mappings_template_with_bar`, which adds the bar field.
## And the bar-pipeline is executed rather than the foo-pipeline because the substitute
## "index_template_substitutions" uses a substitute `settings_template`, so the value of "foo"
## does not get set to an invalid type.
POST _ingest/_simulate?pretty&index=foo-1
{
"docs": [
{
"_id": "asdf",
"_source": {
"foo": "foo",
"bar": "bar"
}
}
],
"component_template_substitutions": {
"settings_template": {
"template": {
"settings": {
"index": {
"default_pipeline": "bar-pipeline"
}
}
}
}
},
"index_template_substitutions": {
"template_1": {
"index_patterns": ["foo*"],
"composed_of": ["mappings_template_with_bar", "settings_template"]
}
}
}
```
`MV_SLICE` is useful, but loading values from lucene frequently sorts
them so `MV_SLICE` is not as useful as you think it is. It's mostly for
after, say, a `SPLIT`. This documents that and adds a link to the
section on multivalues.
It also moves similar docs to a separate paragraph in the docs for
easier reading.
This removes the undocumented `META FUNCTIONS` command that emits
descriptions for all functions. This shouldn't be used because we never
told anyone about it. I'd have preferred if we'd have explicitly
documented it as no public or if we'd have left it snapshot-only. But
sometimes you make a mistake. I'm hopeful no one is relying on it. It
was never reliable and not public.....
* Adds note on reindexing existing data for semantic_text usage
* Adds note about full crawl and full sync
* Style guide related fix
* Update docs/reference/search/search-your-data/semantic-search-semantic-text.asciidoc
Co-authored-by: Liam Thompson <32779855+leemthompo@users.noreply.github.com>
---------
Co-authored-by: Liam Thompson <32779855+leemthompo@users.noreply.github.com>
Including the cluster state in responses to the `POST _cluster/state`
API was deprecated in #90399 (v8.6.0) requiring callers to pass
`?metric=none` to avoid the deprecation warning. This commit adjusts the
behaviour as promised in v9 so that this API never returns the cluster
state, and deprecates the `?metric` parameter itself.
Closes#88978
Today the docs for the `?wait_for_active_shards` parameter say that it
must be a positive integer, proscribing `0`, yet `0` is a legitimate
value for this parameter. This commit fixes this point and rewords the
docs slightly for clarity.
Spells out that third-party EOL schedules don't affect our support. Also
reorders the information to talk about the benefits of the bundled JDK
before mentioning alternatives, and clarifies the division of
responsibilities for "supported" JDKs other than the bundled one.
Today there are a handful of integer settings for `repository-s3`
repositories whose docs link to the page about numeric field types. Yet
these settings are not fields, and do not support floating-point values
either. The convention throughout the rest of the docs is to just call
these things `integer` without linking to anything. This commit aligns
the `repository-s3` docs with this convention.
While working on Date Nanos, I noticed that Least and Greatest didn't have support for datetime. This PR corrects that and adds tests for it.
It seems to me that resolveType() is doing the wrong thing for these functions, as it accepts types that then do not have evaluator mappings, but refactoring that seems out of scope right now.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Adds a default configuration for the ELSER model. The config uses
adaptive allocations to automatically scale. Min number of allocations
is set to 1 for this PR, a follow up with change that to 0 and enable
scale from 0.
This end point is always visible in the GET API.
```
GET _inference
{
"endpoints": [
{
"inference_id": ".elser-2",
"task_type": "sparse_embedding",
"service": "elser",
"service_settings": {
"num_threads": 1,
"model_id": ".elser_model_2",
"adaptive_allocations": {
"enabled": true,
"min_number_of_allocations": 1,
"max_number_of_allocations": 8
}
},
"task_settings": {}
}
]
}
```
The default configuration can be used against without any prior setup.
If the model is not downloaded it is automatically downloaded. If it is
not deployed it is deployed
```
POST _inference/.elser-2
{
"input": "Automagically deploy and infer"
}
...
{
"sparse_embedding": [
{
"is_truncated": false,
"embedding": {
"##fer": 2.2107008,
"deployment": 2.1624098,
"deploy": 2.144009,
"auto": 1.9384763,
```
### Follow up tasks - [ ] Add default config for the E5 text embedding
model - [ ] Select platform specific version - [ ] Scale from 0 - [ ]
Chunking settings - What happens when the end point is deleted, can it
be deleted? - Can the default config be modified - chunking settings for
example? Probably not
This mentions EXPLAIN ANALYZE and EXPLAIN PLAN in the docs for ESQL's
`profile` option. Those are things that folks from PostgreSQL and Oracle
are used to and might search for. And `profile` is the closest thing we
have to them.
EXPLAIN PLAN doesn't run the query - it just tells you what the plan is.
ESQL's `profile` always runs the query. So that's different. But it's
close!
EXPLAIN ANALYZE *does* run the query. It's pretty much the same.
