elastomer-client 0.8.1 → 0.9.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/CHANGELOG.md +4 -0
- data/README.md +7 -7
- data/docs/README.md +8 -8
- data/docs/client.md +19 -19
- data/docs/cluster.md +8 -8
- data/docs/docs.md +9 -9
- data/docs/index.md +8 -9
- data/lib/elastomer/client.rb +4 -4
- data/lib/elastomer/client/bulk.rb +7 -7
- data/lib/elastomer/client/cluster.rb +10 -10
- data/lib/elastomer/client/delete_by_query.rb +1 -1
- data/lib/elastomer/client/docs.rb +24 -24
- data/lib/elastomer/client/index.rb +51 -37
- data/lib/elastomer/client/multi_search.rb +2 -2
- data/lib/elastomer/client/nodes.rb +4 -4
- data/lib/elastomer/client/repository.rb +6 -6
- data/lib/elastomer/client/scroller.rb +4 -4
- data/lib/elastomer/client/snapshot.rb +6 -6
- data/lib/elastomer/client/template.rb +3 -3
- data/lib/elastomer/client/warmer.rb +3 -3
- data/lib/elastomer/middleware/opaque_id.rb +2 -2
- data/lib/elastomer/notifications.rb +3 -3
- data/lib/elastomer/version.rb +1 -1
- data/test/client/index_test.rb +50 -4
- data/test/test_helper.rb +6 -5
- metadata +3 -3
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: 4f92a7cb69e266a5d7d085d3ac4c2cb71689c30d
|
4
|
+
data.tar.gz: a87d3c6dd12b5b243061c9641c1baedb5ff3ae95
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 483643b29967808319ce67e5b6b58458dc6034f9e6df78601a6f9264ad666205648c3117bb940b6f8b58a73086e1589302bf98c12575922c5ef434856b003fa6
|
7
|
+
data.tar.gz: 8e3b0f7bbf2c399d10efd7892d1d216ef6d64c41247c040eb246957162428c2324cbb5e68dcb167ede04a2618a5ab0ddb0584a53be63aad0bc14e968e6ec7886
|
data/CHANGELOG.md
CHANGED
data/README.md
CHANGED
@@ -1,6 +1,6 @@
|
|
1
1
|
# Elastomer Client [](https://travis-ci.org/github/elastomer-client)
|
2
2
|
|
3
|
-
Making a stupid simple
|
3
|
+
Making a stupid simple Elasticsearch client so your project can be smarter!
|
4
4
|
|
5
5
|
## Getting Started
|
6
6
|
|
@@ -15,10 +15,10 @@ $ script/test
|
|
15
15
|
|
16
16
|
## Client
|
17
17
|
|
18
|
-
The client provides a one-to-one mapping to the
|
19
|
-
endpoints](
|
20
|
-
decomposed into logical sections and accessed according to what you
|
21
|
-
to accomplish. Each logical section is represented as a [client
|
18
|
+
The client provides a one-to-one mapping to the Elasticsearch [API
|
19
|
+
endpoints](https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html).
|
20
|
+
The API is decomposed into logical sections and accessed according to what you
|
21
|
+
are trying to accomplish. Each logical section is represented as a [client
|
22
22
|
class](lib/elastomer/client) and a top-level accessor is provided for each.
|
23
23
|
|
24
24
|
#### Cluster
|
@@ -89,7 +89,7 @@ docs.index({
|
|
89
89
|
:_id => 1,
|
90
90
|
:_type => 'tweet',
|
91
91
|
:author => '@pea53',
|
92
|
-
:tweet => 'announcing Elastomer, the stupid simple
|
92
|
+
:tweet => 'announcing Elastomer, the stupid simple Elasticsearch client'
|
93
93
|
})
|
94
94
|
|
95
95
|
docs.search({:query => {:match_all => {}}}, :search_type => 'count')
|
@@ -98,7 +98,7 @@ docs.search({:query => {:match_all => {}}}, :search_type => 'count')
|
|
98
98
|
#### Performance
|
99
99
|
|
100
100
|
By default Elastomer uses Net::HTTP (via Faraday) to communicate with
|
101
|
-
|
101
|
+
Elasticsearch. You may find that Excon performs better for your use. To enable
|
102
102
|
Excon, add it to your bundle and then change your Elastomer initialization
|
103
103
|
thusly:
|
104
104
|
|
data/docs/README.md
CHANGED
@@ -2,20 +2,20 @@
|
|
2
2
|
|
3
3
|
We first started building the Elastomer Client gem when an
|
4
4
|
[official client](https://github.com/elasticsearch/elasticsearch-ruby)
|
5
|
-
was not yet available from
|
6
|
-
provided a one-to-one mapping of the
|
5
|
+
was not yet available from Elasticsearch. We were looking for a client that
|
6
|
+
provided a one-to-one mapping of the Elasticsearch APIs and avoided higher level
|
7
7
|
complexity such as connection pooling, round-robin connections, thrift support,
|
8
|
-
and the like. We think these things
|
9
|
-
|
8
|
+
and the like. We think these things are better handled at different layers and
|
9
|
+
by other software libraries.
|
10
10
|
|
11
|
-
Our goal is to keep our
|
11
|
+
Our goal is to keep our Elasticsearch client simple and then compose
|
12
12
|
higher level functionality from smaller components. This is the UNIX philosophy
|
13
13
|
in action.
|
14
14
|
|
15
|
-
To that end we have tried to be as faithful as possible to the
|
15
|
+
To that end we have tried to be as faithful as possible to the Elasticsearch API
|
16
16
|
with our implementation. There are a few places where it made sense to wrap the
|
17
|
-
|
18
|
-
[scan-scroll](
|
17
|
+
Elasticsearch API inside Ruby idioms. One notable location is the
|
18
|
+
[scan-scroll](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-scroll.html)
|
19
19
|
search type; the Elastomer Client provides a Ruby iterator to work with these
|
20
20
|
types of queries.
|
21
21
|
|
data/docs/client.md
CHANGED
@@ -1,8 +1,8 @@
|
|
1
1
|
# Elastomer Client Component
|
2
2
|
|
3
3
|
All methods in the Elastomer Client gem eventually make an HTTP request to
|
4
|
-
|
5
|
-
class is responsible for connecting to an
|
4
|
+
Elasticsearch. The [`Elastomer::Client`](https://github.com/github/elastomer-client/blob/master/lib/elastomer/client.rb)
|
5
|
+
class is responsible for connecting to an Elasticsearch instance, making HTTP
|
6
6
|
requests, processing the response, and handling errors. Let's look at the
|
7
7
|
details of how `Elastomer::Client` handles HTTP communication.
|
8
8
|
|
@@ -13,10 +13,10 @@ communication. Faraday provides a uniform wrapper around several different HTTP
|
|
13
13
|
clients allowing any of these clients to be used at runtime. Faraday also has
|
14
14
|
the concept of *middlewares* that operate on the HTTP request and response. We
|
15
15
|
use Faraday middleware to encode and decode JSON messages exchanged with
|
16
|
-
|
16
|
+
Elasticsearch.
|
17
17
|
|
18
18
|
Without any options the `Elastomer::Client` will connect to the default
|
19
|
-
|
19
|
+
Elasticsearch URL `http://localhost:9200`. The `Net:HTTP` client from the Ruby
|
20
20
|
standard library will be used.
|
21
21
|
|
22
22
|
```ruby
|
@@ -26,9 +26,9 @@ client.port #=> 9200
|
|
26
26
|
client.url #=> 'http://localhost:9200'
|
27
27
|
```
|
28
28
|
|
29
|
-
[Boxen](https://boxen.github.com) configures
|
29
|
+
[Boxen](https://boxen.github.com) configures Elasticsearch to listen on port
|
30
30
|
`19200` instead of the standard port. We can provide either the full URL or just
|
31
|
-
a different port number if
|
31
|
+
a different port number if Elasticsearch is running on `localhost`.
|
32
32
|
|
33
33
|
```ruby
|
34
34
|
client = Elastomer::Client.new :port => 19200
|
@@ -39,7 +39,7 @@ client.url #=> 'http://localhost:19200'
|
|
39
39
|
client = Elastomer::Client.new :url => "http://localhost:19200"
|
40
40
|
```
|
41
41
|
|
42
|
-
|
42
|
+
Elasticsearch works best with persistent connections. We can use the
|
43
43
|
`Net::HTTP::Persistent` adapter with Faraday.
|
44
44
|
|
45
45
|
```ruby
|
@@ -49,7 +49,7 @@ client = Elastomer::Client.new \
|
|
49
49
|
```
|
50
50
|
|
51
51
|
We also want to configure the `:open_timeout` (for making the initial connection
|
52
|
-
to
|
52
|
+
to Elasticsearch) and the `:read_timeout` (used to limit each request). The open
|
53
53
|
timeout should be short - it defaults to 2 seconds. The read timeout should be
|
54
54
|
longer, but it can vary depending upon the type of request you are making. Large
|
55
55
|
bulk requests will take longer than a quick count query.
|
@@ -59,7 +59,7 @@ timeout can be set for each request.
|
|
59
59
|
|
60
60
|
```ruby
|
61
61
|
client = Elastomer::Client.new \
|
62
|
-
:url => "http
|
62
|
+
:url => "http://localhost:19200",
|
63
63
|
:adapter => :net_http_persistent,
|
64
64
|
:open_timeout => 1,
|
65
65
|
:read_timeout => 5
|
@@ -73,9 +73,9 @@ read timeout is reached. If the connection is left open and reused, then the
|
|
73
73
|
returned data might actually be from a previous request. This can lead to all
|
74
74
|
kinds of horrible data leaks.
|
75
75
|
|
76
|
-
|
76
|
+
Elasticsearch provides an `X-Opaque-Id` request header. Any value set in this
|
77
77
|
request header will be returned in the corresponding response header. This
|
78
|
-
allows the client to correlate the response from
|
78
|
+
allows the client to correlate the response from Elasticsearch with the request
|
79
79
|
that was submitted. We have written an
|
80
80
|
[OpaqueId](https://github.com/github/elastomer-client/blob/master/lib/elastomer/middleware/opaque_id.rb)
|
81
81
|
middleware that will abort any request if the `X-Opaque-Id` headers disagree
|
@@ -109,12 +109,12 @@ HTTP request. The HTTP `head` method does not support a request body and ignores
|
|
109
109
|
this parameter. The other HTTP methods all support request bodies.
|
110
110
|
|
111
111
|
The `:body` value will be converted into JSON format before being sent to
|
112
|
-
|
113
|
-
it is assumed to already be JSON formatted, and it is sent to
|
112
|
+
Elasticsearch unless the body is a String or an Array. If the body is a String
|
113
|
+
it is assumed to already be JSON formatted, and it is sent to Elasticsearch as
|
114
114
|
is without any modifications. When the body is an Array then all the items are
|
115
115
|
joined with a newline character `\n` and a trailing newline is appended; this
|
116
|
-
supports [bulk](
|
117
|
-
indexing and [multi-search](
|
116
|
+
supports [bulk](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html)
|
117
|
+
indexing and [multi-search](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-multi-search.html)
|
118
118
|
requests.
|
119
119
|
|
120
120
|
**:read_timeout**
|
@@ -133,10 +133,10 @@ client.cluster.health \
|
|
133
133
|
```
|
134
134
|
|
135
135
|
In the example above we are waiting for the named index to reach a green state.
|
136
|
-
The `:timeout` of 5 seconds is passed to
|
136
|
+
The `:timeout` of 5 seconds is passed to Elasticsearch. This call will return
|
137
137
|
after 5 seconds even if the index has not yet reached green status. So we set
|
138
138
|
our network call timeout to 7 seconds to ensure we don't kill the request before
|
139
|
-
|
139
|
+
Elasticsearch has responded.
|
140
140
|
|
141
141
|
**:action** and **:context**
|
142
142
|
|
@@ -228,9 +228,9 @@ fatal, then the request is fundamentally flawed and should not be retried.
|
|
228
228
|
Passing a malformed search query or trying to search an index that does not
|
229
229
|
exist are both examples of fatal errors - the request will never succeed.
|
230
230
|
|
231
|
-
If an error is not fatal then it can be retried. If the
|
231
|
+
If an error is not fatal then it can be retried. If the Elasticsearch cluster
|
232
232
|
has a full search queue then any query will fail. It not the fault of the user
|
233
|
-
or the query itself -
|
233
|
+
or the query itself - Elasticsearch just needs more capacity. The query can be
|
234
234
|
safely retried.
|
235
235
|
|
236
236
|
Therein lies the rub, though. Retrying a search or any operation will continue
|
data/docs/cluster.md
CHANGED
@@ -2,8 +2,8 @@
|
|
2
2
|
|
3
3
|
The cluster component deals with commands for managing cluster state and
|
4
4
|
monitoring cluster health. All the commands found under the
|
5
|
-
[cluster API](
|
6
|
-
section of the
|
5
|
+
[cluster API](https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster.html)
|
6
|
+
section of the Elasticsearch documentation are implemented by the
|
7
7
|
[`cluster.rb`](https://github.com/github/elastomer-client/blob/master/lib/elastomer/client/cluster.rb)
|
8
8
|
module and the [`nodes.rb`](https://github.com/github/elastomer-client/blob/master/lib/elastomer/client/nodes.rb)
|
9
9
|
module.
|
@@ -12,13 +12,13 @@ module.
|
|
12
12
|
|
13
13
|
API endpoints dealing with cluster level information and settings are found in
|
14
14
|
the [`Cluster`](lib/elastomer/client/cluster.rb) class. Each of these methods
|
15
|
-
corresponds to an API endpoint described in the
|
15
|
+
corresponds to an API endpoint described in the Elasticsearch documentation
|
16
16
|
(linked to above). The params listed in the documentation can be passed to these
|
17
17
|
methods, so we do not take too much trouble to enumerate them all.
|
18
18
|
|
19
19
|
#### health
|
20
20
|
|
21
|
-
The cluster [health API](
|
21
|
+
The cluster [health API](https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html)
|
22
22
|
returns a very simple cluster health status report.
|
23
23
|
|
24
24
|
```ruby
|
@@ -50,8 +50,8 @@ client.cluster.health \
|
|
50
50
|
#### state & stats
|
51
51
|
|
52
52
|
If you need something more than basic health information, then the
|
53
|
-
[`state`](
|
54
|
-
and [`stats`](
|
53
|
+
[`state`](https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-state.html)
|
54
|
+
and [`stats`](https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-stats.html)
|
55
55
|
endpoints are the next methods to call. Please look through the API
|
56
56
|
documentation linked to above for all the details. And you can play with these
|
57
57
|
endpoints via an IRB session.
|
@@ -67,10 +67,10 @@ client.cluster.stats
|
|
67
67
|
#### settings
|
68
68
|
|
69
69
|
Cluster behavior is controlled via the
|
70
|
-
[settings API](
|
70
|
+
[settings API](https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-update-settings.html).
|
71
71
|
The settings can be retrieved, and some settings can be modified at runtime to
|
72
72
|
control shard allocations, routing, index replicas, and so forth. For example,
|
73
|
-
when performing a [rolling restart](
|
73
|
+
when performing a [rolling restart](https://www.elastic.co/guide/en/elasticsearch/guide/current/_rolling_restarts.html)
|
74
74
|
of a cluster, disabling shard allocation between restarts can reduce the
|
75
75
|
cluster recovery time.
|
76
76
|
|
data/docs/docs.md
CHANGED
@@ -1,8 +1,8 @@
|
|
1
1
|
# Elastomer Documents Component
|
2
2
|
|
3
3
|
The documents components handles all API calls related to
|
4
|
-
[indexing documents](
|
5
|
-
and [searching documents](
|
4
|
+
[indexing documents](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs.html)
|
5
|
+
and [searching documents](https://www.elastic.co/guide/en/elasticsearch/reference/current/search.html).
|
6
6
|
|
7
7
|
Access to the documents component is provided via the `docs` method on the index
|
8
8
|
component or the `docs` method on the client. The `docs` method on the index
|
@@ -68,7 +68,7 @@ This will create a new document in the search index. But what do we do if there
|
|
68
68
|
is a misspelling in the body of our blog post? We'll need to re-index the
|
69
69
|
document.
|
70
70
|
|
71
|
-
|
71
|
+
Elasticsearch assigned our document a unique identifier when we first added it
|
72
72
|
to the index. In order to change this document, we need to supply the unique
|
73
73
|
identifier along with our modified document.
|
74
74
|
|
@@ -86,13 +86,13 @@ docs.index(
|
|
86
86
|
*The `post_body` above is a variable representing the real body of the blog
|
87
87
|
post. I don't want to type it over and over again.*
|
88
88
|
|
89
|
-
You do not have to relay on the auto-generated IDs from
|
89
|
+
You do not have to relay on the auto-generated IDs from Elasticsearch. You can
|
90
90
|
always provide your own IDs; this is recommended if your documents are also
|
91
91
|
stored in a database that provides unique IDs. Using the same IDs in both
|
92
92
|
locations enables you to reconcile documents between the two.
|
93
93
|
|
94
94
|
The `:_id` field is only one of several special fields that control document
|
95
|
-
indexing in
|
95
|
+
indexing in Elasticsearch. The full list of supported fields are enumerated in
|
96
96
|
the `index`
|
97
97
|
[method documentation](https://github.com/github/elastomer-client/blob/master/lib/elastomer/client/docs.rb#L45-56).
|
98
98
|
|
@@ -160,7 +160,7 @@ client.docs.search \
|
|
160
160
|
:type => "post"
|
161
161
|
```
|
162
162
|
|
163
|
-
The `search` method returns the query response from
|
163
|
+
The `search` method returns the query response from Elasticsearch as a ruby
|
164
164
|
Hash. All the keys are represented as Strings. The [hashie](https://github.com/intridea/hashie)
|
165
165
|
project has some useful transforms and wrappers for working with these result
|
166
166
|
sets, but that is left to the user to implement if they so desire. Elastomer
|
@@ -198,7 +198,7 @@ results["hits"]["total"] #=> 1
|
|
198
198
|
The search results always contain the total number of matched documents; even if
|
199
199
|
the `:size` is set to zero or some other number. However this is very inefficient.
|
200
200
|
|
201
|
-
|
201
|
+
Elasticsearch provides specific methods for obtaining the number of documents
|
202
202
|
that match a search. Instead we can specify a `:search_type` tailored for
|
203
203
|
counting.
|
204
204
|
|
@@ -212,9 +212,9 @@ results["hits"]["total"] #=> 1
|
|
212
212
|
|
213
213
|
The `"count"` search type is much more efficient then setting the size to zero.
|
214
214
|
These count queries will return more quickly and consume less memory inside
|
215
|
-
|
215
|
+
Elasticsearch.
|
216
216
|
|
217
|
-
There is also a `count` API method, but the `:
|
217
|
+
There is also a `count` API method, but the `:search_type` approach is even more
|
218
218
|
efficient than the count API.
|
219
219
|
|
220
220
|
#### Deleting
|
data/docs/index.md
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
# Elastomer Index Component
|
2
2
|
|
3
3
|
The index component provides access to the
|
4
|
-
[indices API](
|
4
|
+
[indices API](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices.html)
|
5
5
|
used for index management, settings, mappings, and aliases. Index
|
6
6
|
[warmers](warmers.md) and [templates](templates.md) are handled via their own
|
7
7
|
components. Methods for adding documents to the index and searching those
|
@@ -25,7 +25,6 @@ index.status
|
|
25
25
|
index = client.index
|
26
26
|
index.status :index => "blog"
|
27
27
|
index.status :index => "users"
|
28
|
-
|
29
28
|
```
|
30
29
|
|
31
30
|
You can operate on more than one index, too, by providing a list of index names.
|
@@ -96,19 +95,19 @@ index.update_mapping :post,
|
|
96
95
|
```
|
97
96
|
|
98
97
|
The `:post` type is given twice - once as a method argument, and once in the
|
99
|
-
request body. This is an artifact of the
|
98
|
+
request body. This is an artifact of the Elasticsearch API. We could hide this
|
100
99
|
wart, but the philosophy of the elastomer-client is to be as faithful to the API
|
101
100
|
as possible.
|
102
101
|
|
103
102
|
#### Analysis
|
104
103
|
|
105
|
-
The [analysis](
|
104
|
+
The [analysis](https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis.html)
|
106
105
|
process has the greatest impact on the relevancy of your search results. It is
|
107
106
|
the process of decomposing text into searchable tokens. Understanding this
|
108
107
|
process is important, and creating your own analyzers is as much an art form as
|
109
108
|
it is science.
|
110
109
|
|
111
|
-
|
110
|
+
Elasticsearch provides an [analyze](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-analyze.html)
|
112
111
|
API for exploring the analysis process and return tokens. We can see how
|
113
112
|
individual fields will analyze text.
|
114
113
|
|
@@ -118,7 +117,7 @@ index.analyze "The Role of Morphology in Phoneme Prediction",
|
|
118
117
|
:field => "post.title"
|
119
118
|
```
|
120
119
|
|
121
|
-
And we can explore the default analyzers provided by
|
120
|
+
And we can explore the default analyzers provided by Elasticsearch.
|
122
121
|
|
123
122
|
```ruby
|
124
123
|
client.index.analyze "The Role of Morphology in Phoneme Prediction",
|
@@ -129,13 +128,13 @@ client.index.analyze "The Role of Morphology in Phoneme Prediction",
|
|
129
128
|
|
130
129
|
A common practice when dealing with non-changing data sets (event logs) is to
|
131
130
|
create a new index for each week or month. Only the current index is written to,
|
132
|
-
and the older indices can be made read
|
131
|
+
and the older indices can be made read-only. Eventually, when it is time to
|
133
132
|
expire the data, the older indices can be deleted from the cluster.
|
134
133
|
|
135
134
|
Let's take a look at some simple event log maintenance using elastomer-client.
|
136
135
|
|
137
136
|
```ruby
|
138
|
-
# the previous
|
137
|
+
# the previous month's event log
|
139
138
|
index = client.index "event-log-2014-09"
|
140
139
|
|
141
140
|
# optimize the index to have only 1 segment file (expunges deleted documents)
|
@@ -153,7 +152,7 @@ index.update_settings \
|
|
153
152
|
```
|
154
153
|
|
155
154
|
Now we have a nicely optimized event log index that can be searched but cannot
|
156
|
-
be written to.
|
155
|
+
be written to. Sometime in the future we can delete this index (but we should
|
157
156
|
take a [snapshot](snapshots.md) first).
|
158
157
|
|
159
158
|
```ruby
|
data/lib/elastomer/client.rb
CHANGED
@@ -10,7 +10,7 @@ module Elastomer
|
|
10
10
|
class Client
|
11
11
|
|
12
12
|
# Create a new client that can be used to make HTTP requests to the
|
13
|
-
#
|
13
|
+
# Elasticsearch server.
|
14
14
|
#
|
15
15
|
# opts - The options Hash
|
16
16
|
# :host - the host as a String
|
@@ -48,18 +48,18 @@ module Elastomer
|
|
48
48
|
end
|
49
49
|
alias_method :available?, :ping
|
50
50
|
|
51
|
-
# Returns the version String of the attached
|
51
|
+
# Returns the version String of the attached Elasticsearch instance.
|
52
52
|
def version
|
53
53
|
@version ||= info["version"]["number"]
|
54
54
|
end
|
55
55
|
|
56
|
-
# Returns a Semantic::Version for the attached
|
56
|
+
# Returns a Semantic::Version for the attached Elasticsearch instance.
|
57
57
|
# See https://rubygems.org/gems/semantic
|
58
58
|
def semantic_version
|
59
59
|
Semantic::Version.new(version)
|
60
60
|
end
|
61
61
|
|
62
|
-
# Returns the information Hash from the attached
|
62
|
+
# Returns the information Hash from the attached Elasticsearch instance.
|
63
63
|
def info
|
64
64
|
response = get "/", :action => "cluster.info"
|
65
65
|
response.body
|
@@ -7,7 +7,7 @@ module Elastomer
|
|
7
7
|
# Bulk instance to assemble the operations called in the block into a
|
8
8
|
# bulk request and dispatch it at the end of the block.
|
9
9
|
#
|
10
|
-
# See
|
10
|
+
# See https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html
|
11
11
|
#
|
12
12
|
# body - Request body as a String (required if a block is _not_ given)
|
13
13
|
# params - Optional request parameters as a Hash
|
@@ -142,9 +142,9 @@ module Elastomer
|
|
142
142
|
end
|
143
143
|
|
144
144
|
# The Bulk class provides some abstractions and helper methods for working
|
145
|
-
# with the
|
145
|
+
# with the Elasticsearch bulk API command. Instances of the Bulk class
|
146
146
|
# accumulate indexing and delete operations and then issue a single bulk
|
147
|
-
# API request to
|
147
|
+
# API request to Elasticsearch. Those operations are then executed by the
|
148
148
|
# cluster.
|
149
149
|
#
|
150
150
|
# A maximum request size can be set. As soon as the size of the request
|
@@ -183,12 +183,12 @@ module Elastomer
|
|
183
183
|
# Set the request size in bytes. If the value is nil, then request size
|
184
184
|
# limiting will not be used and a request will only be made when the call
|
185
185
|
# method is called. It is up to the user to ensure that the request does
|
186
|
-
# not exceed
|
186
|
+
# not exceed Elasticsearch request size limits.
|
187
187
|
#
|
188
188
|
# If the value is a number greater than zero, then actions will be
|
189
189
|
# buffered until the request size is met or exceeded. When this happens a
|
190
190
|
# bulk request is issued, queued actions are cleared, and the response
|
191
|
-
# from
|
191
|
+
# from Elasticsearch is returned.
|
192
192
|
def request_size=( value )
|
193
193
|
if value.nil?
|
194
194
|
@request_size = nil
|
@@ -200,12 +200,12 @@ module Elastomer
|
|
200
200
|
# Set the action count. If the value is nil, then action count limiting
|
201
201
|
# will not be used and a request will only be made when the call method
|
202
202
|
# is called. It is up to the user to ensure that the request does not
|
203
|
-
# exceed
|
203
|
+
# exceed Elasticsearch request size limits.
|
204
204
|
#
|
205
205
|
# If the value is a number greater than zero, then actions will be
|
206
206
|
# buffered until the action count is met. When this happens a bulk
|
207
207
|
# request is issued, queued actions are cleared, and the response from
|
208
|
-
#
|
208
|
+
# Elasticsearch is returned.
|
209
209
|
def action_count=(value)
|
210
210
|
if value.nil?
|
211
211
|
@action_count = nil
|