Skip to content

Commit

Permalink
Reorganize Painless doc structure (elastic#42303)
Browse files Browse the repository at this point in the history
  • Loading branch information
jdconrad authored and Gurkan Kaymak committed May 27, 2019
1 parent 4b42db9 commit a21c448
Show file tree
Hide file tree
Showing 32 changed files with 120 additions and 94 deletions.
2 changes: 1 addition & 1 deletion docs/painless/index.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@

include::../Versions.asciidoc[]

include::painless-getting-started.asciidoc[]
include::painless-guide.asciidoc[]

include::painless-lang-spec.asciidoc[]

Expand Down
2 changes: 0 additions & 2 deletions docs/painless/painless-contexts.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -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[]
2 changes: 2 additions & 0 deletions docs/painless/painless-contexts/index.asciidoc
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
include::painless-context-examples.asciidoc[]

include::painless-ingest-processor-context.asciidoc[]

include::painless-update-context.asciidoc[]
Expand Down
Original file line number Diff line number Diff line change
@@ -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[
Expand All @@ -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[]
7 changes: 7 additions & 0 deletions docs/painless/painless-guide/index.asciidoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
include::painless-walkthrough.asciidoc[]

include::painless-method-dispatch.asciidoc[]

include::painless-debugging.asciidoc[]

include::painless-execute-script.asciidoc[]
File renamed without changes.
30 changes: 30 additions & 0 deletions docs/painless/painless-guide/painless-method-dispatch.asciidoc
Original file line number Diff line number Diff line change
@@ -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.
Original file line number Diff line number Diff line change
@@ -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:

Expand Down Expand Up @@ -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.
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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[]
36 changes: 1 addition & 35 deletions docs/painless/painless-lang-spec.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -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[]
35 changes: 35 additions & 0 deletions docs/painless/painless-lang-spec/index.asciidoc
Original file line number Diff line number Diff line change
@@ -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[]
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
2 changes: 0 additions & 2 deletions docs/painless/painless-xref.asciidoc

This file was deleted.

2 changes: 1 addition & 1 deletion docs/reference/ingest/ingest-node.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
29 changes: 27 additions & 2 deletions docs/reference/modules/scripting/painless.asciidoc
Original file line number Diff line number Diff line change
@@ -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].

0 comments on commit a21c448

Please sign in to comment.