Add support for Java High Level REST Client [DATAES-407] #978
Comments
|
Nikita commented I started work on this task. In the worst case, the prototype will be ready by October 29 |
|
Nikita commented After a deep immersion in the high and low-level rest clients, I found out that not everything is as simple as it seemed at first. A huge amount of functionality is simply not implemented in high level client, and for implementation I need to use a low-level client, which is essentially just a http client. In addition, it will be necessary to adapt almost all tests. On the sidelines, it will take another couple of weeks. Next week, I think, I will lay out a prototype in my repository |
|
Don Wellington commented Is there an update? Can I help with tests if you can point me to a repository with the prototype? |
|
ronan quillevere commented Hello, Any update on this ? |
|
Oliver Henlich commented Hi |
|
Oliver Drotbohm commented ronan quillevere – I've removed you last comment as it's offensive and rude. Please be sure to follow our Code of Conduct, thanks |
|
ronan quillevere commented Sorry my last comment was not meant to be rude at all, I do not see how it was offensive. I never blamed or attacked anyone, I just noted that, taking into account that no one is responding on any channel and that last update is from more than 6 month ago, it was (in my opinion) fair to assume that this development has been stopped. Am I right ? Please correct me If I am wrong |
|
Oliver Drotbohm commented Assuming someone's death from the lack of movement on a ticket is rude. There hasn't been any progress on this ticket so far. The SD ES team is working on the project on a purely voluntarily basis |
|
ronan quillevere commented By "dev" I meant the development of the feature not the developer of course ! I would never have supposed something like that ?! |
|
ronan quillevere commented So could you confirm that to your knowledge no one is working on this anymore ? BTW of course thanks for all the voluntarily contributions to all of you ! |
|
Don Wellington commented It looks like we should really wait for the 6.3 release because 6.2 doesn't quite support enough APIs to fully implement ElasticsearchOperations. Particularly, Alias, Mapping, and Settings operations |
|
Don Wellington commented
First, I am going with creating an ElasticsearchRestTemplate that uses the RestHighLevelClient, to maintain TransportClient support through ES 7.0+. Does that sound right? Second, RestHighLevelClient does not implement getClient, so I am going with remove the method from ElasticsearchOperations on the grounds that if you need to get the underlying client you probably need to get the underlying implementation, since you will have to know which client. Alternatively, should I deprecate the getClient() method, and have ElasticsearchRestTemplate throw an unsupported operation exception, and provide a different method like getRestClient()? I need to get the tests passing against a hand deployed elasticsearch, then figure out how to update the testing setup to work with the RestHighLevelClient. Hopefully, I can put together a pull request soon |
|
Artur Konczak commented Hi Don Wellington - good to hear that someone was able to bite this issue - regarding getClient() just make that method to return RestHighLevelClient this will give us access to RestClient via getLowLevelClient. For missing functionalities - we can try to use LowLevelClient or try to create PR for Elasticseach-rest-client with implementation missing feature
|
|
Don Wellington commented I had to take a break. Currently, the ElasticsearchRestTemplate is passing a copy of the ElasticsearchTemplate tests against a hand started Elasticsearch. getSettings, getMappings, and queryAliases were the only things I had to use Low Level Rest Client on. The Alias code was a bit more effort than it should have been because the REST response for aliases didn't quite match up. Probably, why the High Level REST client doesn't support it, yet. I did some backwards compatibility hacks, but I am thinking the getSettings and getMappings interface should be changed to return Settings and Mappings instead of Map some day. Next steps:
|
|
Don Wellington commented Ok. Turns out setting up the test and the RestclientFactoryBean were not nearly as much effort as I thought. Pull Request submitted for review. Let's see what need fixing |
|
Don Wellington commented For anyone interested. |
|
Don Wellington commented Did a quick manual test. ElasticsearchRestTemplate using client and elasticsearch version 6.3.0 is backwards compatible with an elasticsearch cluster running 6.2.2. The bad news is that it is not Junit testable in Maven because I used XContent constructs from Elasticsearch 6.3.0 to handle Mappings, Settings, and Aliases. So, flipping the configuring Elasticsearch.jar to 6.2.2 and rest-client to 6.3.0 for testing doesn't work |
|
Brian Clozel commented Don Wellington Spring Boot (as of the next 2.1 version) already auto-configures elasticsearch clients; see the reference documentation |
|
Fabien Baligand commented Hi, Elasticsearch Java Rest Client 6.4.0 is out today, and is now covering nearly all REST API features ! You can check Java high-level REST client completeness here :
|
|
Don Wellington commented I think I will create a different Issue to track verifying the 6.4.0 High Level Rest Client with no changes. I think a lot of people would appreciate extra compatibility in Spring Data Elasticsearch, which the High Level REST client should help with. Converting the 3 operations that I had to use the low level client in 6.3.0 to use the 6.4.0 high level client would break that. I might check to see if 6.4.0 High Level Client works with 6.3.0 cluster. And, see what Oliver thinks about that configuration |
|
Fabien Baligand commented Here is what says Elastic concerning compatibility : Up to me, if you don’t use new body options brought by Elasticsearch server 6.4, you keep compatibility. What is the compatibility goal in the PR ? 6.3+ ? 6.x ? 5.x + 6.x ? |
|
ezeprimo commented hi, what is the status for this issue? it is in revision? i dont see advances
|
|
Tobias Günther commented This is not a minor needed feature to be honest. |
|
Fabien Baligand commented The PR implementing this feature is now merged. |
|
Oliver Drotbohm commented General support for the high-level client has been merged recently and is scheduled for release with Moore M1 in December 2018. We're planning a more general revision for the release train after Moore |
|
Mark Paluch commented Adding REST High Level Client support with this ticket only. Moved the TransportClient removal into DATAES-495 |
|
ronan quillevere commented Excellent news ! Well done ! |
|
Fabien Baligand commented Great to see it will soon available in Moore M1 ! |
|
ezeprimo commented yes, excelent news! |
|
Vijay882 commented Can you please confirm if this fix is available in below version. compile group: 'org.springframework.data', name: 'spring-data-elasticsearch', version: '3.1.10.RELEASE'
|
|
Don Wellington commented Nope. 3.2.0.M1 or better. Try 3.2.0.RC3 . It looks like Spring Data Moore GA is not far off, so I suspect it would be low risk to start working with 3.2.0.RC3 while waiting for Moore GA.
|
|
Josh Wand commented when this is final, will the spring boot autoconfiguration be updated to use the highlevelrestclient as default? or will that be a separate JIRA? |
spring-projects-issues
added
type: enhancement
Nikita opened DATAES-407 and commented
Starting from version 5.6.0 of Elasticsearch, a new Java client has been released: the Java High Level REST Client. This new client is designed to replace the TransportClient in Java applications which will be deprecated in future versions of Elasticsearch. So we must migrate our codebase from old TransportClient to new REST client.
Quotation from official documentation
Quotation from a blog post about the state of the official Elasticsearch Java clients
Reference URL: https://www.elastic.co/guide/en/elasticsearch/client/java-rest/5.6/_motivations_around_a_new_java_client.html
Issue Links:
("is depended on by")
("is duplicated by")
("supersedes")
19 votes, 34 watchers
The text was updated successfully, but these errors were encountered: