This change adds support for enable and disable user APIs to the high
level rest client. There is a common request base class for both
requests with specific requests that simplify the use of these APIs.
The response for these APIs is simply an empty object so a new response
class has been created for cases where we expect an empty response to
be returned.
Finally, the put user documentation has been moved to the proper
location that is not within an x-pack sub directory and the document
tags no longer contain x-pack.
See #29827
In an effort to encapsulate the different clients, the request
converters are being shuffled around. This splits the MigrationClient
request converters.
In an effort to encapsulate the different clients, the request
converters are being shuffled around. This splits the SnapshotClient
request converters.
This change collapses all metrics aggregations classes into a single package `org.elasticsearch.aggregations.metrics`.
It also restricts the visibility of some classes (aggregators and factories) that should not be used outside of the package.
Relates #22868
The main benefit of the upgrade for users is the search optimization for top scored documents when the total hit count is not needed. However this optimization is not activated in this change, there is another issue opened to discuss how it should be integrated smoothly.
Some comments about the change:
* Tests that can produce negative scores have been adapted but we need to forbid them completely: #33309Closes#32899
This commit adds a security client to the high level rest client, which
includes an implementation for the put user api. As part of these
changes, a new request and response class have been added that are
specific to the high level rest client. One change here is that the response
was previously wrapped inside a user object. The plan is to remove this
wrapping and this PR adds an unwrapped response outside of the user
object so we can remove the user object later on.
See #29827
* HLRC: Adding pojos for get job stats
HLRC: Adding pojos for job stats request
* HLRC: Adding job stats pojos
* HLRC: ML job stats
* Minor syntax changes and adding license headers
* minor comment change
* Moving to client package, minor changes
* Addressing PR comments
* removing bad sleep
* addressing minor comment around test methods
* adding toplevel random fields for tests
* addressing minor review comments
In #29623 we added `Request` object flavored requests to the low level
REST client and in #30315 we deprecated the old `performRequest`s. In a
long series of PRs I've changed all of the old style requests. This
drops the deprecated methods and will be released with 7.0.
With the switch to client side request and response objects, we need a
client side version of RefreshPolicy. This change adds a client side
version of RefreshPolicy along with a method to add it to the
parameters of a request. The existing method to add
WriteRequest.RefreshPolicy to the parameters of a request is now
deprecated.
There are many requests that allow the user to set a few timeouts
on. This class will allow requests impl'd in HLRC to extend from, and
allow users to set those values without significant work to add them to
every request.
The Validatable class comes from an old class in server code, that
assumed null was returned in the event of validation having no
errors. This commit changes that to use Optional, which is cleaner than
passing around null objects.
In #29623 we added `Request` object flavored requests to the low level
REST client and in #30315 we deprecated the old `performRequest`s. This
changes all calls in the `client` and `distribution` projects to use
the new versions.
We used to set `maxScore` to `0` within `TopDocs` in situations where there is really no score as the size was set to `0` and scores were not even tracked. In such scenarios, `Float.Nan` is more appropriate, which gets converted to `max_score: null` on the REST layer. That's also more consistent with lucene which set `maxScore` to `Float.Nan` when merging empty `TopDocs` (see `TopDocs#merge`).
The HLRC has historically reused the same Request and Response classes
that the server module uses. This commit deprecates the use of any
server module Request and Response classes, and adds a small bit of
validation logic that differs from server slightly, in that it does not
assume a check for a null ValidationException class is not enough to
determine if validation failed.
* HLRC: Adding GET ML Job info API
* HLRC: Adding GET Job ML API
* Fixing QueryPage license header
* Adding serialization tests, addressing minor issues
* Renaming querypage, changing the dependency on it
* Making things immutable
* Fixing build failure due to method rename
This reworks how we configure the `shadow` plugin in the build. The major
change is that we no longer bundle dependencies in the `compile` configuration,
instead we bundle dependencies in the new `bundle` configuration. This feels
more right because it is a little more "opt in" rather than "opt out" and the
name of the `bundle` configuration is a little more obvious.
As an neat side effect of this, the `runtimeElements` configuration used when
one project depends on another now contains exactly the dependencies needed
to run the project so you no longer need to reference projects that use the
shadow plugin like this:
```
testCompile project(path: ':client:rest-high-level', configuration: 'shadow')
```
You can instead use the much more normal:
```
testCompile "org.elasticsearch.client:elasticsearch-rest-high-level-client:${version}"
```
This commit duplicates the `MlRestTestStateCleaner` to make sure
all ML data is removed after each test. After implementing
the job and datafeed APIs in the HLRC, we shall replace this
implementation with one using the HLRC itself.
Closes#32993
* HLRC: Adding ML Close Job API
HLRC: Adding ML Close Job API
* reconciling request converters
* Adding serialization tests and addressing PR comments
* Changing constructor order
All of the Elasticsearch logging infrastructure relies on log4j but we
don't want the high level rest client to rely on log4j2. All of its
logging goes through commons-logging because our dependencies drag in
commons logging already. Anyway, this bans direct use of Elasticsearch's
logging infrastructure in the high level REST client. It is still
possible to use it indirectly though and there isn't anything we can
really do about that until we split the high level rest client from
Elasticsearch's server jar.
Michael Basnight
Jay Modi
Benjamin Trent
Jim Ferenczi
Dimitris Athanasiou
Sohaib Iftikhar
Alpar Torok
Nik Everett
Armin Braun
Albert Zaharovits
Luca Cavanna
markharwood