Skip to content

Commit 14344d0

Browse files
committed
Simplify (a lot) code includes
1 parent 7169692 commit 14344d0

File tree

16 files changed

+99
-471
lines changed

16 files changed

+99
-471
lines changed

docs/reference/api-conventions/blocking-async.md

Lines changed: 1 addition & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -9,15 +9,8 @@ API clients come in two flavors: blocking and asynchronous. All methods on async
99

1010
Both flavors can be used at the same time depending on your needs, sharing the same transport object:
1111

12-
<!-- :::include
12+
% :::include-code src={{doc-tests-src}}/api_conventions/ApiConventionsTest.java tag=blocking-and-async
1313
```java
14-
ElasticsearchTransport transport = ...
15-
:::{include} {doc-tests-src}/api_conventions/ApiConventionsTest.java[blocking-and-async]
16-
```
17-
-->
18-
% :::include::start -- do not remove
19-
```java
20-
ElasticsearchTransport transport = ...
2114
// Synchronous blocking client
2215
ElasticsearchClient client = new ElasticsearchClient(transport);
2316

@@ -39,7 +32,6 @@ asyncClient
3932
}
4033
});
4134
```
42-
% :::include::end -- do not remove
4335

4436
Although we won’t go in deeper details on asynchronous programming in Java, remember to handle failures of asynchronous tasks. It’s easy to overlook them and have errors go unnoticed.
4537

docs/reference/api-conventions/building-objects.md

Lines changed: 8 additions & 36 deletions
Original file line numberDiff line numberDiff line change
@@ -10,15 +10,9 @@ mapped_pages:
1010

1111
All data types in the Java API Client are immutable. Object creation uses the [builder pattern](https://www.informit.com/articles/article.aspx?p=1216151&seqNum=2) that was popularized in **Effective Java** in 2008.
1212

13-
<!-- :::include
13+
% :::include-code src={{doc-tests-src}}/api_conventions/ApiConventionsTest.java tag=builders
1414
```java
15-
ElasticsearchClient client = ...
16-
:::{include} {doc-tests-src}/api_conventions/ApiConventionsTest.java[builders]
17-
```
18-
-->
19-
% :::include::start -- do not remove
20-
```java
21-
ElasticsearchClient client = ...
15+
ElasticsearchClient client = createClient();
2216
CreateIndexResponse createResponse = client.indices().create(
2317
new CreateIndexRequest.Builder()
2418
.index("my-index")
@@ -28,7 +22,6 @@ CreateIndexResponse createResponse = client.indices().create(
2822
.build()
2923
);
3024
```
31-
% :::include::end -- do not remove
3225

3326
Note that a builder should not be reused after its `build()` method has been called.
3427

@@ -37,15 +30,9 @@ Note that a builder should not be reused after its `build()` method has been cal
3730

3831
Although this works nicely, having to instantiate builder classes and call the `build()` method is a bit verbose. So every property setter in the Java API Client also accepts a lambda expression that takes a newly created builder as a parameter and returns a populated builder. The snippet above can also be written as:
3932

40-
<!-- :::include
41-
```java
42-
ElasticsearchClient client = ...
43-
:::{include} {doc-tests-src}/api_conventions/ApiConventionsTest.java[builder-lambdas]
44-
```
45-
-->
46-
% :::include::start -- do not remove
33+
% :::include-code src={{doc-tests-src}}/api_conventions/ApiConventionsTest.java tag=builder-lambdas
4734
```java
48-
ElasticsearchClient client = ...
35+
ElasticsearchClient client = createClient();
4936
CreateIndexResponse createResponse = client.indices()
5037
.create(createIndexBuilder -> createIndexBuilder
5138
.index("my-index")
@@ -54,21 +41,14 @@ CreateIndexResponse createResponse = client.indices()
5441
)
5542
);
5643
```
57-
% :::include::end -- do not remove
5844

5945
This approach allows for much more concise code, and also avoids importing classes (and even remembering their names) since types are inferred from the method parameter signature.
6046

6147
Note in the above example that builder variables are only used to start a chain of property setters. The names of these variables are therefore unimportant and can be shortened to improve readability:
6248

63-
<!-- :::include
49+
% :::include-code src={{doc-tests-src}}/api_conventions/ApiConventionsTest.java tag=builder-lambdas-short
6450
```java
65-
ElasticsearchClient client = ...
66-
:::{include} {doc-tests-src}/api_conventions/ApiConventionsTest.java[builder-lambdas-short]
67-
```
68-
-->
69-
% :::include::start -- do not remove
70-
```java
71-
ElasticsearchClient client = ...
51+
ElasticsearchClient client = createClient();
7252
CreateIndexResponse createResponse = client.indices()
7353
.create(c -> c
7454
.index("my-index")
@@ -77,21 +57,14 @@ CreateIndexResponse createResponse = client.indices()
7757
)
7858
);
7959
```
80-
% :::include::end -- do not remove
8160

8261
Builder lambdas become particularly useful with complex nested queries like the one below, taken from the [intervals query API documentation](elasticsearch://reference/query-languages/query-dsl/query-dsl-intervals-query.md).
8362

8463
This example also highlights a useful naming convention for builder parameters in deeply nested structures. For lambda expressions with a single argument, Kotlin provides the implicit `it` parameter and Scala allows use of `_`. This can be approximated in Java by using an underscore or a single letter prefix followed by a number representing the depth level (i.e. `_0`, `_1`, or `b0`, `b1` and so on). Not only does this remove the need to create throw-away variable names, but it also improves code readability. Correct indentation also allows the structure of the query to stand out.
8564

86-
<!-- :::include
87-
```java
88-
ElasticsearchClient client = ...
89-
:::{include} {doc-tests-src}/api_conventions/ApiConventionsTest.java[builder-intervals]
90-
```
91-
-->
92-
% :::include::start -- do not remove
65+
% :::include-code src={{doc-tests-src}}/api_conventions/ApiConventionsTest.java tag=builder-intervals
9366
```java
94-
ElasticsearchClient client = ...
67+
ElasticsearchClient client = createClient();
9568
SearchResponse<SomeApplicationData> results = client
9669
.search(b0 -> b0
9770
.query(b1 -> b1
@@ -126,7 +99,6 @@ SearchResponse<SomeApplicationData> results = client
12699
SomeApplicationData.class // <1>
127100
);
128101
```
129-
% :::include::end -- do not remove
130102

131103
1. Search results will be mapped to `SomeApplicationData` instances to be readily available to the application.
132104

docs/reference/api-conventions/lists-maps.md

Lines changed: 2 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -12,12 +12,7 @@ Properties of type `List` and `Map` are exposed by object builders as a set of o
1212

1313
Object builders create immutable objects, and this also applies to list and map properties that are made immutable at object construction time.
1414

15-
<!-- :::include
16-
```java
17-
:::{include} {doc-tests-src}/api_conventions/ApiConventionsTest.java[collections]
18-
```
19-
-->
20-
% :::include::start -- do not remove
15+
% :::include-code src={{doc-tests-src}}/api_conventions/ApiConventionsTest.java tag=collections
2116
```java
2217
// Prepare a list of index names
2318
List<String> names = Arrays.asList("idx-a", "idx-b", "idx-c");
@@ -53,7 +48,6 @@ SearchRequest search = SearchRequest.of(r -> r
5348
a -> a.histogram(h -> h.field("price")))
5449
);
5550
```
56-
% :::include::end -- do not remove
5751

5852
## List and map values are never `null` [_list_and_map_values_are_never_null]
5953

@@ -63,12 +57,7 @@ For lists and maps however, applications often only care about whether they’re
6357

6458
If you ever need to distinguish between a missing (undefined) optional collection and an effectively-empty collection returned by {{es}}, the `ApiTypeHelper` class provides a utility method to distinguish them:
6559

66-
<!-- :::include
67-
```java
68-
:::{include} {doc-tests-src}/api_conventions/ApiConventionsTest.java[optional-collections]
69-
```
70-
-->
71-
% :::include::start -- do not remove
60+
% :::include-code src={{doc-tests-src}}/api_conventions/ApiConventionsTest.java tag=optional-collections
7261
```java
7362
NodeStatistics stats = NodeStatistics.of(b -> b
7463
.total(1)
@@ -84,7 +73,6 @@ assertEquals(0, stats.failures().size());
8473
// - and if needed we can know it was actually not defined
8574
assertFalse(ApiTypeHelper.isDefined(stats.failures()));
8675
```
87-
% :::include::end -- do not remove
8876

8977
:::{include} /reference/_snippets/doc-tests-blurb.md
9078
:::

docs/reference/api-conventions/loading-json.md

Lines changed: 4 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -31,12 +31,7 @@ Consider a resource file `some-index.json` containing an index definition:
3131

3232
You can create an index from that definition as follows:
3333

34-
<!-- :::include
35-
```java
36-
:::{include} {doc-tests-src}/api_conventions/LoadingJsonTest.java[load-index]
37-
```
38-
-->
39-
% :::include::start -- do not remove
34+
% :::include-code src={{doc-tests-src}}/api_conventions/LoadingJsonTest.java tag=load-index
4035
```java
4136
InputStream input = this.getClass()
4237
.getResourceAsStream("some-index.json"); // <1>
@@ -48,7 +43,6 @@ CreateIndexRequest req = CreateIndexRequest.of(b -> b
4843

4944
boolean created = client.indices().create(req).acknowledged();
5045
```
51-
% :::include::end -- do not remove
5246

5347
1. open an input stream for the JSON resource file.
5448
2. populate the index creation request with the resource file contents.
@@ -59,12 +53,7 @@ boolean created = client.indices().create(req).acknowledged();
5953

6054
Similarly, you can read documents to be stored in {{es}} from data files:
6155

62-
<!-- :::include
63-
```java
64-
:::{include} {doc-tests-src}/api_conventions/LoadingJsonTest.java[ingest-data]
65-
```
66-
-->
67-
% :::include::start -- do not remove
56+
% :::include-code src={{doc-tests-src}}/api_conventions/LoadingJsonTest.java tag=ingest-data
6857
```java
6958
FileReader file = new FileReader(new File(dataDir, "document-1.json"));
7059

@@ -77,7 +66,6 @@ req = IndexRequest.of(b -> b
7766

7867
client.index(req);
7968
```
80-
% :::include::end -- do not remove
8169

8270
1. when calling `withJson()` on data structures that have generic type parameters, these generic types will be considered to be `JsonData`.
8371

@@ -87,12 +75,7 @@ client.index(req);
8775

8876
You can combine `withJson()` with regular calls to setter methods. The example below loads the query part of a search request from a `String` and programmatically adds an aggregation.
8977

90-
<!-- :::include
91-
```java
92-
:::{include} {doc-tests-src}/api_conventions/LoadingJsonTest.java[query]
93-
```
94-
-->
95-
% :::include::start -- do not remove
78+
% :::include-code src={{doc-tests-src}}/api_conventions/LoadingJsonTest.java tag=query
9679
```java
9780
Reader queryJson = new StringReader(
9881
"{" +
@@ -123,7 +106,6 @@ Map<String, Aggregate> aggs = client
123106
.search(aggRequest, Void.class) // <3>
124107
.aggregations();
125108
```
126-
% :::include::end -- do not remove
127109

128110
1. loads the query from the JSON string.
129111
2. adds the aggregation.
@@ -135,12 +117,7 @@ Map<String, Aggregate> aggs = client
135117

136118
The `withJson()` methods are partial deserializers: the properties loaded from the JSON will set property values or replace the previous ones, but will not reset other properties not found in the JSON input. You can use this to combine multiple JSON snippets to build complex search requests. In the example below, we combine separate definitions of a query that selects some documents and an aggregation that is run on the results of this query.
137119

138-
<!-- :::include
139-
```java
140-
:::{include} {doc-tests-src}/api_conventions/LoadingJsonTest.java[query-and-agg]
141-
```
142-
-->
143-
% :::include::start -- do not remove
120+
% :::include-code src={{doc-tests-src}}/api_conventions/LoadingJsonTest.java tag=query-and-agg
144121
```java
145122
Reader queryJson = new StringReader(
146123
"{" +
@@ -184,7 +161,6 @@ Map<String, Aggregate> aggs = client
184161
.search(aggRequest, Void.class)
185162
.aggregations();
186163
```
187-
% :::include::end -- do not remove
188164

189165
1. set max number of returned document to 100 for queries.
190166
2. we do not want any matching document in aggregations.

0 commit comments

Comments
 (0)