OpenSearch/docs
Robert Muir e3ce6c9048 Painless: add fielddata accessors (.value/.values/.distance()/etc)
This gives better coverage and consistency with the scripting APIs, by
whitelisting the primary search scripting API classes and using them instead
of only Map and List methods.

For example, accessing fields can now be done with `.value` instead of `.0`
because `getValue()` is whitelisted. For now, access to a document's fields in
this way (loads) are fast-pathed in the code, to avoid dynamic overhead.

Access to geo fields and geo distance functions is now supported.

TODO: date support (e.g. whitelist ReadableDateTime methods as a start)
TODO: improve docs (like expressions and groovy have for document's fields)
TODO: remove fast-path hack

Closes #18169

Squashed commit of the following:

commit ec9f24b2424891a7429bb4c0a03f9868cba0a213
Author: Robert Muir <rmuir@apache.org>
Date:   Thu May 5 17:59:37 2016 -0400

    cutover to <Def> instead of <Object> here

commit 9edb1550438acd209733bc36f0d2e0aecf190ecb
Author: Robert Muir <rmuir@apache.org>
Date:   Thu May 5 17:03:02 2016 -0400

    add fast-path for docvalues field loads

commit f8e38c0932fccc0cfa217516130ad61522e59fe5
Author: Robert Muir <rmuir@apache.org>
Date:   Thu May 5 16:47:31 2016 -0400

    Painless: add fielddata accessors (.value/.values/.distance()/etc)
2016-05-05 18:38:41 -04:00
..
community-clients Add kotlin query DSL to community clients (#17943) 2016-04-26 16:03:50 +02:00
groovy-api Backs out early link fix. 2015-10-22 15:00:35 -07:00
java-api Update client.asciidoc 2016-05-04 14:07:28 +09:00
perl Updated copyright years to include 2016 (#17808) 2016-04-18 12:39:23 +02:00
plugins Fixed a bad asciidoc link 2016-05-04 22:48:51 +02:00
python Updated copyright years to include 2016 (#17808) 2016-04-18 12:39:23 +02:00
reference Painless: add fielddata accessors (.value/.values/.distance()/etc) 2016-05-05 18:38:41 -04:00
resiliency Update resiliency page (#17586) 2016-04-07 12:17:13 +02:00
ruby Updated copyright years to include 2016 (#17808) 2016-04-18 12:39:23 +02:00
src/test/java/org/elasticsearch/smoketest Generate and run tests from the docs 2016-05-05 13:58:03 -04:00
README.asciidoc Generate and run tests from the docs 2016-05-05 13:58:03 -04:00
build.gradle Generate and run tests from the docs 2016-05-05 13:58:03 -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 `// AUTOSENSE` are automatically annotated with "VIEW IN
SENSE" in the documentation and are automatically tested by the command
`gradle :docs:check`. By default `// AUTOSENSE` 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 `// AUTOSENSE`.
  * `// 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 `// AUTOSENSE` 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`.
* `// 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.