New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DATAES-407 - Support for HighLevelRestClient #216
Conversation
ElasticsearchRestTemplate Removed getClient() from EsOperations Made CustomMethodRepositoryTest for both TranportClient and RestClient to make sure the new Template worked with a Repository.
|
Thank you for your contribution. We will need some time to review your changes. |
|
Awesome job with rest client @donrw. All changes are looking good - both transport and rest clients are working alongside - this is a good base to start gradually removing support for transport client and give people time to adapt to the changes. |
|
changes are in this branch - https://github.com/spring-projects/spring-data-elasticsearch/tree/DATAES-407 |
|
Waiting for this to be merged. |
|
We missed merging this pull request for the last release candidate. We're now in the RC phase of the Lovelace release train and merging such a significant change, even though the change introduces primarily a new Template API implementation, we want to reduce the risk by including the merge for the next, Moore, release train. |
|
Really sad to hear this @mp911de :( |
|
GA for Lovelace is scheduled for 19 of September - after that date we should be able to merge changes into master https://github.com/spring-projects/spring-data-commons/wiki/Release-Train-Moore |
|
Hi @mp911de - I should be able to merge this PR to master this week |
|
Great ! |
| http\://www.springframework.org/schema/data/elasticsearch/spring-elasticsearch-1.0.xsd=org/springframework/data/elasticsearch/config/spring-elasticsearch-1.0.xsd | ||
| http\://www.springframework.org/schema/data/elasticsearch/spring-elasticsearch.xsd=org/springframework/data/elasticsearch/config/spring-elasticsearch-1.0.xsd | ||
| http\://www.springframework.org/schema/data/elasticsearch/spring-elasticsearch-1.0.xsd=org/springframework/data/elasticsearch/config/spring-elasticsearch-1.0.xsd | ||
| http\://www.springframework.org/schema/data/elasticsearch/spring-elasticsearch-1.1.xsd=org/springframework/data/elasticsearch/config/spring-elasticsearch-1.1.xsd |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should rather upgrade schema versions to 3.2 to reflect the relation between the schema and the artifact version.
| */ | ||
| @RunWith(SpringJUnit4ClassRunner.class) | ||
| @ContextConfiguration("classpath:elasticsearch-rest-template-test.xml") | ||
| public class ElasticsearchRestTemplateTests { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about parametrizing the test so we can run the exact same tests against two different implementations? Would reduce test code and removes the possibility of deviations as both implementations are expected to behave the same way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes - that will be a nice option to do that in that way - I'm not sure if new client cover all old cases but we can try to go with this idea, My plan is to merge PR and them reduce duplication in test between transport client and http client.
|
Great to see this PR is merged ! |
|
@akonczak – Thanks for the merge! Would you mind fixing up the merge to avoid the merge commit and make sure that the commit messages follow the usual template? We can do that ourselves as well, I just wanted to avoid we step on each other's toes 🙃. |
|
@olivergierke - it has been a while sine I was playing with SDES project and I have forget a lot of procedures, my mistake - I need just confirmation from you that you are happy that I will alter/override history of master |
|
Please go ahead with the cleanups. We can add polishing commits on top. It’s just hard to keep track of what’s actually included with that merge commit. |
…plate Original pull request: #216
|
Hi, We have started using AWS Elastic Cluster and it, in turn, depends on Rest Client instead of Transport Client... 3.1.3.RELEASE does not include these changes... Please let me know when these changes will be included in the official Release... |
|
We do not backport Features of this size. We intend to ship a first milestone of 3.2 in December.
Am 28. Nov. 2018, 18:18 +0100 schrieb harshahst <notifications@github.com>:
… Hi, We have started using AWS Elastic Cluster and it, in turn, depends on Rest Client instead of Transport Client... 3.1.3.RELEASE does not include these changes... Please let me know when these changes will be included in the official Release...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Must use Spring Data Moore milestone 1 since it is not GA yet. See spring-projects/spring-data-elasticsearch#216 GNP-5408.
Added an ElasticsearchRestTemplate and support for XML configuration of HighLevelRestClient.
ElasticSearchOperations no longer has getClient(). So, that will be a breaking change if anyone uses it.
Inclusive of changes for DATAES-468, since that pull request isn't accepted and I neglected to baseline DATAES-407 work on that branch and my git history go screwed up, so it is all squashed into here.
I decided to set the infrastructure.xml node client to http-enabled=true and import it for rest client tests. I am a little worried that we may need to do something to check for an unused port and assign appropriately for 100% reliability, and propagate that to the rest client configuration. I don't know anything about the build server to know if there is a chance of port collision. Two branches of spring-data-elasticsearch on the same build agent? Maybe for another day...
I altered CustomMethodRepositoryTest to do a test with both the old ElasticsearchTemplate and ElasticsearchRestTemplate to double check compatibility of the ElasticsearchRestTemplate. I didn't think doubling up all the repository tests was worth the effort.