1
1
The ES|QL documentation is composed of static content and generated content.
2
2
The static content exists in this directory and can be edited by hand.
3
- However, the sub-directories ` _snippets ` , ` images ` and ` kibana ` contain mostly
4
- generated content.
3
+ However, the subdirectories ` _snippets ` , ` images ` and ` kibana ` contain a mix
4
+ of static and generated content, and so updating them is a bit more involved.
5
+
6
+ ## Static content
7
+
8
+ The root ` esql ` directory and the following two subdirectories contain static content:
9
+ * ` commands ` - contains the static content for the ES|QL commands.
10
+ This content will typically contain mostly ` include ` directives for content in the ` _snippets ` or ` images ` directories.
11
+ * ` functions-operators ` - contains the static content for the ES|QL functions and operators.
12
+ Again this will contain mostly ` include ` directives for content in the ` _snippets ` or ` images ` directories.
13
+
14
+ ## Mixed static and generated content
15
+
16
+ Generated content is created by running the ESQL tests in the ` x-pack/plugin/esql ` module.
17
+ It will be written into three subdirectories of the ` esql ` directory:
5
18
6
19
### _ snippets
7
20
8
- In ` _snippets ` there are files that can be included within other files
9
- using the [ File Inclusion] ( https://elastic.github.io/docs-builder/syntax/file_inclusion/ )
21
+ In ` _snippets ` there are files that can be included within other files using the
22
+ [ File Inclusion] ( https://elastic.github.io/docs-builder/syntax/file_inclusion/ )
10
23
feature of the Elastic Docs V3 system.
11
24
Most, but not all, files in this directory are generated.
12
25
In particular the directories ` _snippets/functions/* ` and ` _snippets/operators/* `
@@ -21,7 +34,7 @@ contain subdirectories that are mostly generated:
21
34
22
35
Most functions can use the generated docs generated in the ` layout ` directory.
23
36
If we need something more custom for the function we can make a file in this
24
- directory that can ` include:: ` any parts of the files above.
37
+ directory that can ` include ` any parts of the files above.
25
38
26
39
To regenerate the files for a function run its tests using gradle.
27
40
For example to generate docs for the ` CASE ` function:
@@ -34,17 +47,140 @@ To regenerate the files for all functions run all of ESQL's tests using gradle:
34
47
./gradlew :x-pack:plugin:esql:test
35
48
```
36
49
50
+ #### Lists
51
+
52
+ The ` _snippets/lists ` directory contains re-usable content for lists of commands, functions or operators.
53
+ Whenever adding a command, function or operator, you usually need to add it to one of these lists.
54
+ The lists should also match natural groupings of the commands, functions or operators.
55
+ For example, when adding an aggregation function, add to the ` aggregation-functions.md ` file.
56
+
57
+ #### Commands
58
+
59
+ The ` _snippets/commands ` directory contains the content for the ES|QL commands.
60
+ There are two subdirectories, one static and one generated:
61
+ * ` layout ` - contains the static content for the ES|QL commands.
62
+ The files in this directory are the main content for the documentation for the commands.
63
+ They are not generated, and so this is the primary place to edit the content, or add new commands.
64
+ * ` examples ` - contains the generated content for the ES|QL commands.
65
+ The files in this directory are generated from the test ` CommandDocsTests ` in the ` x-pack/plugin/esql ` module.
66
+ The structure of the subdirectories mimics the csv-spec files and test tags used in the tests.
67
+
68
+ Including generated examples in the command documentation is done by using the include directive.
69
+
37
70
### images
38
71
39
- The ` images ` directory contains ` functions ` and ` operators ` sub-directories with
72
+ The ` images ` directory contains ` functions ` and ` operators ` subdirectories with
40
73
the ` *.svg ` files used to describe the syntax of each function or operator.
41
74
These are all generated by the same tests that generate the functions and operators docs above.
42
75
43
76
### kibana
44
77
45
- The ` kibana ` directory contains ` definition ` and ` docs ` sub-directories that are generated:
78
+ The ` kibana ` directory contains ` definition ` and ` docs ` subdirectories that are generated:
46
79
47
80
* ` kibana/definition ` - function definitions for kibana's ESQL editor
48
81
* ` kibana/docs ` - the inline docs for kibana
49
82
50
83
These are also generated as part of the unit tests described above.
84
+
85
+ ## Under the hood
86
+
87
+ There are three overlapping mechanisms for generating the content:
88
+ * The ` AbstractFunctionTestCase ` class generates the content for all the functions and most operators.
89
+ This class makes use of the ` DocsV3Support ` class to generate the content.
90
+ It uses the ` @FunctionInfo ` and ` @Param ` annotations on function and operator classes to know what content should be generated.
91
+ All tests that extend this class will automatically generate the content for the functions they test.
92
+ * Some operators do not have a clear class or test class, and so the content is generated by custom
93
+ tests that do not extend the ` AbstractOperatorTestCase ` class. See, for example, operators such as ` Cast :: ` ,
94
+ which uses ` CastOperatorTests ` to call directly into the ` DocsV3Support ` class to generate the content.
95
+ * Commands do not have dedicated classes or test classes with annotation that can be used.
96
+ For this reason, the command documentation is generated by the ` CommandDocsTests ` class.
97
+ Currently, this only covers tested examples used in the documentation, and all other commands
98
+ content is static.
99
+ Since there are no annotations to mark which examples to use, the command documentation
100
+ relies on the docs author providing the knowledge of which examples to use by creating subdirectories
101
+ and examples files that match the csv-spec files and tags to include.
102
+
103
+ To help differentiate between the static and generated content, the generated content is prefixed with a comment:
104
+ ```
105
+ % This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it.
106
+ ```
107
+
108
+ ## Tutorials
109
+
110
+ ### Adding a new command
111
+
112
+ When adding a new command, for example adding the ` CHANGE_POINT ` command, do the following:
113
+ 1 . Create a new file in the ` _snippets/commands/layout ` directory with the name of the command, for example ` change_point.md ` .
114
+ 2 . Add the content for the command to the file. See other files in this directory for examples.
115
+ 3 . Add the command to the list in ` _snippets/lists/processing-commands.md ` .
116
+ 4 . Add an include directive to the ` commands/processing-commands.md ` file to include the new command.
117
+ 5 . Add tested examples to the ` _snippets/commands/examples ` directory. See below for details.
118
+
119
+ ### Adding examples to commands
120
+
121
+ When adding tested examples to a command, for example adding an example to the ` CHANGE_POINT ` command, do the following:
122
+ * Make sure you have an example in an appropriate csv-spec file in the ` x-pack/plugin/esql/qa/testFixtures/src/main/resources/ ` directory.
123
+ * Make sure the example has a tag that is unique in that file, and matches the intent of the test, or the docs reason for including that test.
124
+ * If you only want to show the query, and no results, then do not tag the results table,
125
+ otherwise tag the results table with a tag that has the same name as the query tag, but with the suffix ` -result ` .
126
+ * Create a file with the name of the tag in a subdirectory with the name of the csv-spec file
127
+ in the ` _snippets/commands/examples ` directory. While you could add the content to that file, it is not necessary, merely that the file exists
128
+ * Run the test ` CommandDocsTests ` in the ` x-pack/plugin/esql ` module to generate the content.
129
+
130
+ For example, we tag the following test in change_point.csv-spec:
131
+
132
+ ```
133
+ example for docs
134
+ required_capability: change_point
135
+
136
+ // tag::changePointForDocs[]
137
+ ROW key=[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25]
138
+ | MV_EXPAND key
139
+ | EVAL value = CASE(key<13, 0, 42)
140
+ | CHANGE_POINT value ON key
141
+ | WHERE type IS NOT NULL
142
+ // end::changePointForDocs[]
143
+ ;
144
+
145
+ // tag::changePointForDocs-result[]
146
+ key:integer | value:integer | type:keyword | pvalue:double
147
+ 13 | 42 | step_change | 0.0
148
+ // end::changePointForDocs-result[]
149
+ ;
150
+ ```
151
+
152
+ Then we create the file ` _snippets/commands/examples/change_point.csv-spec/changePointForDocs.md ` with the content:
153
+ ```
154
+ This should be overwritten
155
+ ```
156
+
157
+ Then we run the test ` CommandDocsTests ` in the ` x-pack/plugin/esql ` module to generate the content.
158
+
159
+ Now the content of the changePointForDocs.md file should have been updated:
160
+
161
+ ```
162
+ % This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it.
163
+
164
+ \```esql
165
+ ROW key=[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25]
166
+ | MV_EXPAND key
167
+ | EVAL value = CASE(key<13, 0, 42)
168
+ | CHANGE_POINT value ON key
169
+ | WHERE type IS NOT NULL
170
+ \```
171
+
172
+ | key:integer | value:integer | type:keyword | pvalue:double |
173
+ | --- | --- | --- | --- |
174
+ | 13 | 42 | step_change | 0.0 |
175
+ ```
176
+
177
+ Finally include this file in the ` CHANGE_POINT ` command file ` _snippets/commands/layout/change_point.md ` :
178
+
179
+ ```
180
+ **Examples**
181
+
182
+ The following example shows the detection of a step change:
183
+
184
+ :::{include} ../examples/change_point.csv-spec/changePointForDocs.md
185
+ :::
186
+ ```
0 commit comments