My customer is currently facing a versioning problem. We have an
application 'A' that depends (Maven) of ElasticSearch API, which
communicates by TransportClient with centralized ElasticSearch Server 'B'.
The problem is : when we upgrades 'B', we need to upgrade the Maven
dependency in application 'A', which is not a desired coupling design in
the long term. I guess this is a common problem for many companies that you
should be aware of already.
I saw some topics that said ES promised to leverage this design by avoiding
being version dependant in a future API version. Right now, we are aiming
either to :
Wait for a solution from ES (in a reasonable time)
Migrate completely to a full REST architecture bypassing the API
I hope you can address the 1) before thinking about the 2). What can you
say about this problem and how could/would you solution it ?
Asking that because having different elasticsearch versions should work starting elasticsearch 1.0.
This does not apply to Java versions that need to be consistent.
My customer is currently facing a versioning problem. We have an application 'A' that depends (Maven) of Elasticsearch API, which communicates by TransportClient with centralized Elasticsearch Server 'B'.
The problem is : when we upgrades 'B', we need to upgrade the Maven dependency in application 'A', which is not a desired coupling design in the long term. I guess this is a common problem for many companies that you should be aware of already.
I saw some topics that said ES promised to leverage this design by avoiding being version dependant in a future API version. Right now, we are aiming either to :
Wait for a solution from ES (in a reasonable time)
Migrate completely to a full REST architecture bypassing the API
I hope you can address the 1) before thinking about the 2). What can you say about this problem and how could/would you solution it ?
Version A is 1.1.2 and B should be above soon or late. The integration team
had a problem with A already upgrading the server but if from the 1.0 there
"should not" be any dependency problem, I should maybe dig the problems
they had exactly.
Asking that because having different elasticsearch versions should work
starting elasticsearch 1.0.
This does not apply to Java versions that need to be consistent.
My customer is currently facing a versioning problem. We have an
application 'A' that depends (Maven) of Elasticsearch API, which
communicates by TransportClient with centralized Elasticsearch Server 'B'.
The problem is : when we upgrades 'B', we need to upgrade the Maven
dependency in application 'A', which is not a desired coupling design in
the long term. I guess this is a common problem for many companies that you
should be aware of already.
I saw some topics that said ES promised to leverage this design by
avoiding being version dependant in a future API version. Right now, we are
aiming either to :
Wait for a solution from ES (in a reasonable time)
Migrate completely to a full REST architecture bypassing the API
I hope you can address the 1) before thinking about the 2). What can you
say about this problem and how could/would you solution it ?
Version A is 1.1.2 and B should be above soon or late. The integration
team had a problem with A already upgrading the server but if from the 1.0
there "should not" be any dependency problem, I should maybe dig the
problems they had exactly.
Asking that because having different elasticsearch versions should work
starting elasticsearch 1.0.
This does not apply to Java versions that need to be consistent.
My customer is currently facing a versioning problem. We have an
application 'A' that depends (Maven) of Elasticsearch API, which
communicates by TransportClient with centralized Elasticsearch Server 'B'.
The problem is : when we upgrades 'B', we need to upgrade the Maven
dependency in application 'A', which is not a desired coupling design in
the long term. I guess this is a common problem for many companies that you
should be aware of already.
I saw some topics that said ES promised to leverage this design by
avoiding being version dependant in a future API version. Right now, we are
aiming either to :
Wait for a solution from ES (in a reasonable time)
Migrate completely to a full REST architecture bypassing the API
I hope you can address the 1) before thinking about the 2). What can you
say about this problem and how could/would you solution it ?
Version A is 1.1.2 and B should be above soon or late. The integration team had a problem with A already upgrading the server but if from the 1.0 there "should not" be any dependency problem, I should maybe dig the problems they had exactly.
Asking that because having different elasticsearch versions should work starting elasticsearch 1.0.
This does not apply to Java versions that need to be consistent.
My customer is currently facing a versioning problem. We have an application 'A' that depends (Maven) of Elasticsearch API, which communicates by TransportClient with centralized Elasticsearch Server 'B'.
The problem is : when we upgrades 'B', we need to upgrade the Maven dependency in application 'A', which is not a desired coupling design in the long term. I guess this is a common problem for many companies that you should be aware of already.
I saw some topics that said ES promised to leverage this design by avoiding being version dependant in a future API version. Right now, we are aiming either to :
Wait for a solution from ES (in a reasonable time)
Migrate completely to a full REST architecture bypassing the API
I hope you can address the 1) before thinking about the 2). What can you say about this problem and how could/would you solution it ?
Ok, I tried locally with my own ES server 1.4.2 and I didn't notice any
problem. We are investigating the team that encountered some problems and
are waiting for their returns. Hope it doesn't have any link with ES
versioning.
Version A is 1.1.2 and B should be above soon or late. The integration
team had a problem with A already upgrading the server but if from the 1.0
there "should not" be any dependency problem, I should maybe dig the
problems they had exactly.
Asking that because having different elasticsearch versions should work
starting elasticsearch 1.0.
This does not apply to Java versions that need to be consistent.
My customer is currently facing a versioning problem. We have an
application 'A' that depends (Maven) of Elasticsearch API, which
communicates by TransportClient with centralized Elasticsearch Server 'B'.
The problem is : when we upgrades 'B', we need to upgrade the Maven
dependency in application 'A', which is not a desired coupling design in
the long term. I guess this is a common problem for many companies that you
should be aware of already.
I saw some topics that said ES promised to leverage this design by
avoiding being version dependant in a future API version. Right now, we are
aiming either to :
Wait for a solution from ES (in a reasonable time)
Migrate completely to a full REST architecture bypassing the API
I hope you can address the 1) before thinking about the 2). What can you
say about this problem and how could/would you solution it ?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.