Reorganize Painless doc structure (#42303)
This commit is contained in:
parent
39fbed1577
commit
813db163d8
|
@ -3,7 +3,7 @@
|
|||
|
||||
include::../Versions.asciidoc[]
|
||||
|
||||
include::painless-getting-started.asciidoc[]
|
||||
include::painless-guide.asciidoc[]
|
||||
|
||||
include::painless-lang-spec.asciidoc[]
|
||||
|
||||
|
|
|
@ -54,6 +54,4 @@ specialized code may define new ways to use a Painless script.
|
|||
| {xpack-ref}/transform-script.html[Elasticsearch Documentation]
|
||||
|====
|
||||
|
||||
include::painless-contexts/painless-context-examples.asciidoc[]
|
||||
|
||||
include::painless-contexts/index.asciidoc[]
|
||||
|
|
|
@ -1,3 +1,5 @@
|
|||
include::painless-context-examples.asciidoc[]
|
||||
|
||||
include::painless-ingest-processor-context.asciidoc[]
|
||||
|
||||
include::painless-update-context.asciidoc[]
|
||||
|
|
|
@ -1,11 +1,14 @@
|
|||
[[painless-guide]]
|
||||
== Painless Guide
|
||||
|
||||
_Painless_ is a simple, secure scripting language designed specifically for use
|
||||
with Elasticsearch. It is the default scripting language for Elasticsearch and
|
||||
can safely be used for inline and stored scripts. For a detailed description of
|
||||
the Painless syntax and language features, see the
|
||||
{painless}/painless-lang-spec.html[Painless Language Specification].
|
||||
can safely be used for inline and stored scripts. For a jump start into
|
||||
Painless, see <<painless-walkthrough, A Brief Painless Walkthrough>>. For a
|
||||
detailed description of the Painless syntax and language features, see the
|
||||
<<painless-lang-spec, Painless Language Specification>>.
|
||||
|
||||
[[painless-features]]
|
||||
You can use Painless anywhere scripts can be used in Elasticsearch. Painless
|
||||
You can use Painless anywhere scripts are used in Elasticsearch. Painless
|
||||
provides:
|
||||
|
||||
* Fast performance: Painless scripts https://benchmarks.elastic.co/index.html#search_qps_scripts[
|
||||
|
@ -18,7 +21,9 @@ complete list of available classes and methods.
|
|||
* Optional typing: Variables and parameters can use explicit types or the
|
||||
dynamic `def` type.
|
||||
|
||||
* Syntax: Extends Java's syntax to provide http://groovy-lang.org/index.html[
|
||||
Groovy-style] scripting language features that make scripts easier to write.
|
||||
* Syntax: Extends a subset of Java's syntax to provide additional scripting
|
||||
language features.
|
||||
|
||||
* Optimizations: Designed specifically for Elasticsearch scripting.
|
||||
|
||||
include::painless-guide/index.asciidoc[]
|
|
@ -0,0 +1,7 @@
|
|||
include::painless-walkthrough.asciidoc[]
|
||||
|
||||
include::painless-method-dispatch.asciidoc[]
|
||||
|
||||
include::painless-debugging.asciidoc[]
|
||||
|
||||
include::painless-execute-script.asciidoc[]
|
|
@ -0,0 +1,30 @@
|
|||
[[modules-scripting-painless-dispatch]]
|
||||
=== How painless dispatches functions
|
||||
|
||||
Painless uses receiver, name, and https://en.wikipedia.org/wiki/Arity[arity]
|
||||
for method dispatch. For example, `s.foo(a, b)` is resolved by first getting
|
||||
the class of `s` and then looking up the method `foo` with two parameters. This
|
||||
is different from Groovy which uses the
|
||||
https://en.wikipedia.org/wiki/Multiple_dispatch[runtime types] of the
|
||||
parameters and Java which uses the compile time types of the parameters.
|
||||
|
||||
The consequence of this that Painless doesn't support overloaded methods like
|
||||
Java, leading to some trouble when it whitelists classes from the Java
|
||||
standard library. For example, in Java and Groovy, `Matcher` has two methods:
|
||||
`group(int)` and `group(String)`. Painless can't whitelist both of these methods
|
||||
because they have the same name and the same number of parameters. So instead it
|
||||
has `group(int)` and `namedGroup(String)`.
|
||||
|
||||
We have a few justifications for this different way of dispatching methods:
|
||||
|
||||
1. It makes operating on `def` types simpler and, presumably, faster. Using
|
||||
receiver, name, and arity means that when Painless sees a call on a `def` object it
|
||||
can dispatch the appropriate method without having to do expensive comparisons
|
||||
of the types of the parameters. The same is true for invocations with `def`
|
||||
typed parameters.
|
||||
2. It keeps things consistent. It would be genuinely weird for Painless to
|
||||
behave like Groovy if any `def` typed parameters were involved and Java
|
||||
otherwise. It'd be slow for it to behave like Groovy all the time.
|
||||
3. It keeps Painless maintainable. Adding the Java or Groovy like method
|
||||
dispatch *feels* like it'd add a ton of complexity which'd make maintenance and
|
||||
other improvements much more difficult.
|
|
@ -1,10 +1,5 @@
|
|||
[[painless-getting-started]]
|
||||
== Getting Started with Painless
|
||||
|
||||
include::painless-description.asciidoc[]
|
||||
|
||||
[[painless-examples]]
|
||||
=== Painless Examples
|
||||
[[painless-walkthrough]]
|
||||
=== A Brief Painless Walkthrough
|
||||
|
||||
To illustrate how Painless works, let's load some hockey stats into an Elasticsearch index:
|
||||
|
||||
|
@ -121,7 +116,7 @@ GET hockey/_search
|
|||
|
||||
|
||||
[float]
|
||||
===== Missing values
|
||||
==== Missing values
|
||||
|
||||
`doc['field'].value` throws an exception if
|
||||
the field is missing in a document.
|
||||
|
@ -198,7 +193,7 @@ POST hockey/_update/1
|
|||
==== Dates
|
||||
|
||||
Date fields are exposed as
|
||||
`ReadableDateTime`, so they support methods like `getYear`, `getDayOfWeek`
|
||||
`ZonedDateTime`, so they support methods like `getYear`, `getDayOfWeek`
|
||||
or e.g. getting milliseconds since epoch with `getMillis`. To use these
|
||||
in a script, leave out the `get` prefix and continue with lowercasing the
|
||||
rest of the method name. For example, the following returns every hockey
|
||||
|
@ -365,38 +360,3 @@ Note: all of the `_update_by_query` examples above could really do with a
|
|||
{ref}/query-dsl-script-query.html[script query] it wouldn't be as efficient
|
||||
as using any other query because script queries aren't able to use the inverted
|
||||
index to limit the documents that they have to check.
|
||||
|
||||
[[modules-scripting-painless-dispatch]]
|
||||
=== How painless dispatches functions
|
||||
|
||||
Painless uses receiver, name, and https://en.wikipedia.org/wiki/Arity[arity]
|
||||
for method dispatch. For example, `s.foo(a, b)` is resolved by first getting
|
||||
the class of `s` and then looking up the method `foo` with two parameters. This
|
||||
is different from Groovy which uses the
|
||||
https://en.wikipedia.org/wiki/Multiple_dispatch[runtime types] of the
|
||||
parameters and Java which uses the compile time types of the parameters.
|
||||
|
||||
The consequence of this that Painless doesn't support overloaded methods like
|
||||
Java, leading to some trouble when it whitelists classes from the Java
|
||||
standard library. For example, in Java and Groovy, `Matcher` has two methods:
|
||||
`group(int)` and `group(String)`. Painless can't whitelist both of these methods
|
||||
because they have the same name and the same number of parameters. So instead it
|
||||
has `group(int)` and `namedGroup(String)`.
|
||||
|
||||
We have a few justifications for this different way of dispatching methods:
|
||||
|
||||
1. It makes operating on `def` types simpler and, presumably, faster. Using
|
||||
receiver, name, and arity means that when Painless sees a call on a `def` object it
|
||||
can dispatch the appropriate method without having to do expensive comparisons
|
||||
of the types of the parameters. The same is true for invocations with `def`
|
||||
typed parameters.
|
||||
2. It keeps things consistent. It would be genuinely weird for Painless to
|
||||
behave like Groovy if any `def` typed parameters were involved and Java
|
||||
otherwise. It'd be slow for it to behave like Groovy all the time.
|
||||
3. It keeps Painless maintainable. Adding the Java or Groovy like method
|
||||
dispatch *feels* like it'd add a ton of complexity which'd make maintenance and
|
||||
other improvements much more difficult.
|
||||
|
||||
include::painless-debugging.asciidoc[]
|
||||
|
||||
include::painless-execute-script.asciidoc[]
|
|
@ -17,38 +17,4 @@ into Java Virtual Machine (JVM) byte code and executed against a standard JVM.
|
|||
This specification uses ANTLR4 grammar notation to describe the allowed syntax.
|
||||
However, the actual Painless grammar is more compact than what is shown here.
|
||||
|
||||
include::painless-comments.asciidoc[]
|
||||
|
||||
include::painless-keywords.asciidoc[]
|
||||
|
||||
include::painless-literals.asciidoc[]
|
||||
|
||||
include::painless-identifiers.asciidoc[]
|
||||
|
||||
include::painless-variables.asciidoc[]
|
||||
|
||||
include::painless-types.asciidoc[]
|
||||
|
||||
include::painless-casting.asciidoc[]
|
||||
|
||||
include::painless-operators.asciidoc[]
|
||||
|
||||
include::painless-operators-general.asciidoc[]
|
||||
|
||||
include::painless-operators-numeric.asciidoc[]
|
||||
|
||||
include::painless-operators-boolean.asciidoc[]
|
||||
|
||||
include::painless-operators-reference.asciidoc[]
|
||||
|
||||
include::painless-operators-array.asciidoc[]
|
||||
|
||||
include::painless-statements.asciidoc[]
|
||||
|
||||
include::painless-scripts.asciidoc[]
|
||||
|
||||
include::painless-functions.asciidoc[]
|
||||
|
||||
include::painless-lambdas.asciidoc[]
|
||||
|
||||
include::painless-regexes.asciidoc[]
|
||||
include::painless-lang-spec/index.asciidoc[]
|
|
@ -0,0 +1,35 @@
|
|||
include::painless-comments.asciidoc[]
|
||||
|
||||
include::painless-keywords.asciidoc[]
|
||||
|
||||
include::painless-literals.asciidoc[]
|
||||
|
||||
include::painless-identifiers.asciidoc[]
|
||||
|
||||
include::painless-variables.asciidoc[]
|
||||
|
||||
include::painless-types.asciidoc[]
|
||||
|
||||
include::painless-casting.asciidoc[]
|
||||
|
||||
include::painless-operators.asciidoc[]
|
||||
|
||||
include::painless-operators-general.asciidoc[]
|
||||
|
||||
include::painless-operators-numeric.asciidoc[]
|
||||
|
||||
include::painless-operators-boolean.asciidoc[]
|
||||
|
||||
include::painless-operators-reference.asciidoc[]
|
||||
|
||||
include::painless-operators-array.asciidoc[]
|
||||
|
||||
include::painless-statements.asciidoc[]
|
||||
|
||||
include::painless-scripts.asciidoc[]
|
||||
|
||||
include::painless-functions.asciidoc[]
|
||||
|
||||
include::painless-lambdas.asciidoc[]
|
||||
|
||||
include::painless-regexes.asciidoc[]
|
|
@ -1,2 +0,0 @@
|
|||
Ready to start scripting with Painless? See {painless}/painless-getting-started.html[Getting Started with Painless] in the guide to the
|
||||
{painless}/painless.html[Painless Scripting Language].
|
|
@ -563,7 +563,7 @@ template for all indexes that hold data that needs pre-index processing.
|
|||
[[conditionals-with-regex]]
|
||||
=== Conditionals with the Regular Expressions
|
||||
The `if` conditional is implemented as a Painless script, which requires
|
||||
{painless}//painless-examples.html#modules-scripting-painless-regex[explicit support for regular expressions].
|
||||
{painless}//painless-regexes.html[explicit support for regular expressions].
|
||||
|
||||
`script.painless.regex.enabled: true` must be set in `elasticsearch.yml` to use regular
|
||||
expressions in the `if` condition.
|
||||
|
|
|
@ -1,7 +1,32 @@
|
|||
[[modules-scripting-painless]]
|
||||
=== Painless Scripting Language
|
||||
|
||||
include::../../../painless/painless-description.asciidoc[]
|
||||
_Painless_ is a simple, secure scripting language designed specifically for use
|
||||
with Elasticsearch. It is the default scripting language for Elasticsearch and
|
||||
can safely be used for inline and stored scripts. To get started with
|
||||
Painless, see the {painless}/painless-guide.html[Painless Guide]. For a
|
||||
detailed description of the Painless syntax and language features, see the
|
||||
{painless}/painless-lang-spec.html[Painless Language Specification].
|
||||
|
||||
Ready to start scripting with Painless? See {painless}/painless-getting-started.html[Getting Started with Painless] in the guide to the
|
||||
[[painless-features]]
|
||||
You can use Painless anywhere scripts can be used in Elasticsearch. Painless
|
||||
provides:
|
||||
|
||||
* Fast performance: Painless scripts https://benchmarks.elastic.co/index.html#search_qps_scripts[
|
||||
run several times faster] than the alternatives.
|
||||
|
||||
* Safety: Fine-grained whitelist with method call/field granularity. See the
|
||||
{painless}/painless-api-reference.html[Painless API Reference] for a
|
||||
complete list of available classes and methods.
|
||||
|
||||
* Optional typing: Variables and parameters can use explicit types or the
|
||||
dynamic `def` type.
|
||||
|
||||
* Syntax: Extends a subset of Java's syntax to provide additional scripting
|
||||
language features.
|
||||
|
||||
* Optimizations: Designed specifically for Elasticsearch scripting.
|
||||
|
||||
Ready to start scripting with Painless? See the
|
||||
{painless}/painless-guide.html[Painless Guide] for the
|
||||
{painless}/index.html[Painless Scripting Language].
|
Loading…
Reference in New Issue