OpenSearch/docs
Jim Ferenczi 1764ec56b3 Fixed naming inconsistency for fields/stored_fields in the APIs (#20166)
This change replaces the fields parameter with stored_fields when it makes sense.
This is dictated by the renaming we made in #18943 for the search API.

The following list of endpoint has been changed to use `stored_fields` instead of `fields`:
* get
* mget
* explain

The documentation and the rest API spec has been updated to cope with the changes for the following APIs:
* delete_by_query
* get
* mget
* explain

The `fields` parameter has been deprecated for the following APIs (it is replaced by _source filtering):
* update: the fields are extracted from the _source directly.
* bulk: the fields parameter is used but fields are extracted from the source directly so it is allowed to have non-stored fields.

Some APIs still have the `fields` parameter for various reasons:
* cat.fielddata: the fields paramaters relates to the fielddata fields that should be printed.
* indices.clear_cache: used to indicate which fielddata fields should be cleared.
* indices.get_field_mapping: used to filter fields in the mapping.
* indices.stats: get stats on fields (stored or not stored).
* termvectors: fields are retrieved from the stored fields if possible and extracted from the _source otherwise.
* mtermvectors:
* nodes.stats: the fields parameter is used to concatenate completion_fields and fielddata_fields so it's not related to stored_fields at all.

Fixes #20155
2016-09-13 20:54:41 +02:00
..
community-clients Add otto-de/flummi client to plugins 2016-07-06 14:31:58 +02:00
groovy-api Remove most of the need for `// NOTCONSOLE` 2016-09-06 10:32:54 -04:00
java-api Update docs for LatLonPoint cut over 2016-09-13 12:18:21 -05:00
java-rest Bumped doc versions to 6.0.0-alpha1 2016-09-08 18:29:18 +02:00
perl Updated copyright years to include 2016 (#17808) 2016-04-18 12:39:23 +02:00
plugins Bumped doc versions to 6.0.0-alpha1 2016-09-08 18:29:18 +02:00
python Remove most of the need for `// NOTCONSOLE` 2016-09-06 10:32:54 -04:00
reference Fixed naming inconsistency for fields/stored_fields in the APIs (#20166) 2016-09-13 20:54:41 +02:00
resiliency Documentation changes for wait_for_active_shards (#19581) 2016-08-02 09:15:01 -04:00
ruby Updated copyright years to include 2016 (#17808) 2016-04-18 12:39:23 +02:00
src/test Rename client yaml test infrastructure 2016-07-26 13:53:44 -04:00
README.asciidoc Fail yaml tests and docs snippets that get unexpected warnings 2016-08-04 15:23:05 -04:00
build.gradle Disable regexes by default in painless 2016-09-12 14:09:43 -04:00

README.asciidoc

The Elasticsearch docs are in AsciiDoc format and can be built using the
Elasticsearch documentation build process.

See: https://github.com/elastic/docs

Snippets marked with `// CONSOLE` are automatically annotated with "VIEW IN
SENSE" in the documentation and are automatically tested by the command
`gradle :docs:check`. By default `// CONSOLE` snippet runs as its own isolated
test. You can manipulate the test execution in the following ways:

* `// TEST`: Explicitly marks a snippet as a test. Snippets marked this way
are tests even if they don't have `// CONSOLE`.
  * `// TEST[s/foo/bar/]`: Replace `foo` with `bar` in the test. This should be
  used sparingly because it makes the test "lie". Sometimes, though, you can use
  it to make the tests more clear.
  * `// TEST[catch:foo]`: Used to expect errors in the requests. Replace `foo`
  with `request` to expect a 400 error, for example. If the snippet contains
  multiple requests then only the last request will expect the error.
  * `// TEST[continued]`: Continue the test started in the last snippet. Between
  tests the nodes are cleaned: indexes are removed, etc. This will prevent that.
  This is really useful when you have text and snippets that work together to
  tell the story of some use case because it merges the snippets (and thus the
  use case) into one big test.
  * `// TEST[skip:reason]`: Skip this test. Replace `reason` with the actual
  reason to skip the test. Snippets without `// TEST` or `// CONSOLE` aren't
  considered tests anyway but this is useful for explicitly documenting the
  reason why the test shouldn't be run.
  * `// TEST[setup:name]`: Run some setup code before running the snippet. This
  is useful for creating and populating indexes used in the snippet. The setup
  code is defined in `docs/build.gradle`.
  * `// TEST[warning:some warning]`: Expect the response to include a `Warning`
  header. If the response doesn't include a `Warning` header with the exact
  text then the test fails. If the response includes `Warning` headers that
  aren't expected then the test fails.
* `// TESTRESPONSE`: Matches this snippet against the body of the response of
  the last test. If the response is JSON then order is ignored. With
  `// TEST[continued]` you can make tests that contain multiple command snippets
  and multiple response snippets.
  * `// TESTRESPONSE[s/foo/bar/]`: Substitutions. See `// TEST[s/foo/bar]`.
* `// TESTSETUP`: Marks this snippet as the "setup" for all other snippets in
  this file. This is a somewhat natural way of structuring documentation. You
  say "this is the data we use to explain this feature" then you add the
  snippet that you mark `// TESTSETUP` and then every snippet will turn into
  a test that runs the setup snippet first. See the "painless" docs for a file
  that puts this to good use. This is fairly similar to `// TEST[setup:name]`
  but rather than the setup defined in `docs/build.gradle` the setup is defined
  right in the documentation file.

Any place you can use json you can use elements like `$body.path.to.thing`
which is replaced on the fly with the contents of the thing at `path.to.thing`
in the last response.