Re: Elastic Search API : heavy coupling design

2015-02-05 Thread Amaury Fages
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.

2015-02-02 11:34 GMT+01:00 David Pilato :

> This should work AFAIK.
>
>
> --
> *David Pilato* | *Technical Advocate* | *Elasticsearch.com
> *
> @dadoonet  | @elasticsearchfr
>  | @scrutmydocs
> 
>
>
>
> Le 2 févr. 2015 à 10:04, Amaury Fages  a écrit :
>
> I have more information :
> Version A is 1.1.2 as said before and target of B is 1.4 or 1.5.
>
> Can you confirm the compatibility ?
>
> 2015-01-30 17:32 GMT+01:00 Amaury Fages :
>
>> Thank you for answering.
>>
>> 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.
>>
>> 2015-01-30 17:18 GMT+01:00 David Pilato :
>>
>>> What is your version A?
>>> And version B?
>>>
>>> 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.
>>>
>>>
>>> --
>>> *David Pilato* | *Technical Advocate* | *Elasticsearch.com
>>> *
>>> @dadoonet  | @elasticsearchfr
>>>  | @scrutmydocs
>>> 
>>>
>>>
>>>
>>> Le 30 janv. 2015 à 15:42, Amaury Fages  a écrit :
>>>
>>> Hello everyone,
>>>
>>> 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 :
>>>
>>> 1) Wait for a solution from ES (in a reasonable time)
>>> 2) 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 ?
>>>
>>> Best regards,
>>>
>>> Amaury FAGES.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "elasticsearch" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to elasticsearch+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/elasticsearch/b2e13fe4-1da4-4a76-8b03-4c0e553cd887%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "elasticsearch" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/elasticsearch/hiOsFiPaZnY/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> elasticsearch+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/elasticsearch/764D4229-6F7B-4435-92F3-3930F02601D9%40pilato.fr
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "elasticsearch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elasticsearch+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elasticsearch/CAL2m5Fdf7h6aS5wuadXk_4epoK4yVSqB3107iY7oj6b49tkpJA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "elasticsearch" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elasticsearch/hiOsFiPaZnY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> el

Re: Elastic Search API : heavy coupling design

2015-02-02 Thread David Pilato
This should work AFAIK.


-- 
David Pilato | Technical Advocate | Elasticsearch.com
@dadoonet  | @elasticsearchfr 
 | @scrutmydocs 




> Le 2 févr. 2015 à 10:04, Amaury Fages  a écrit :
> 
> I have more information :
> Version A is 1.1.2 as said before and target of B is 1.4 or 1.5.
> 
> Can you confirm the compatibility ?
> 
> 2015-01-30 17:32 GMT+01:00 Amaury Fages  >:
> Thank you for answering.
> 
> 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.
> 
> 2015-01-30 17:18 GMT+01:00 David Pilato  >:
> What is your version A?
> And version B?
> 
> 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.
> 
> 
> -- 
> David Pilato | Technical Advocate | Elasticsearch.com 
> 
> @dadoonet  | @elasticsearchfr 
>  | @scrutmydocs 
> 
> 
> 
> 
>> Le 30 janv. 2015 à 15:42, Amaury Fages > > a écrit :
>> 
>> Hello everyone,
>> 
>> 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 :
>> 
>> 1) Wait for a solution from ES (in a reasonable time)
>> 2) 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 ?
>> 
>> Best regards,
>> 
>> Amaury FAGES. 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "elasticsearch" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elasticsearch+unsubscr...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elasticsearch/b2e13fe4-1da4-4a76-8b03-4c0e553cd887%40googlegroups.com
>>  
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "elasticsearch" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/elasticsearch/hiOsFiPaZnY/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> elasticsearch+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/elasticsearch/764D4229-6F7B-4435-92F3-3930F02601D9%40pilato.fr
>  
> .
> 
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "elasticsearch" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elasticsearch+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/elasticsearch/CAL2m5Fdf7h6aS5wuadXk_4epoK4yVSqB3107iY7oj6b49tkpJA%40mail.gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elasticsearch+unsubscr...@googlegroups.com.
To view this discuss

Re: Elastic Search API : heavy coupling design

2015-02-02 Thread Amaury Fages
I have more information :
Version A is 1.1.2 as said before and target of B is 1.4 or 1.5.

Can you confirm the compatibility ?

2015-01-30 17:32 GMT+01:00 Amaury Fages :

> Thank you for answering.
>
> 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.
>
> 2015-01-30 17:18 GMT+01:00 David Pilato :
>
>> What is your version A?
>> And version B?
>>
>> 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.
>>
>>
>> --
>> *David Pilato* | *Technical Advocate* | *Elasticsearch.com
>> *
>> @dadoonet  | @elasticsearchfr
>>  | @scrutmydocs
>> 
>>
>>
>>
>> Le 30 janv. 2015 à 15:42, Amaury Fages  a écrit :
>>
>> Hello everyone,
>>
>> 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 :
>>
>> 1) Wait for a solution from ES (in a reasonable time)
>> 2) 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 ?
>>
>> Best regards,
>>
>> Amaury FAGES.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "elasticsearch" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elasticsearch+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elasticsearch/b2e13fe4-1da4-4a76-8b03-4c0e553cd887%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>  --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "elasticsearch" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/elasticsearch/hiOsFiPaZnY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> elasticsearch+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elasticsearch/764D4229-6F7B-4435-92F3-3930F02601D9%40pilato.fr
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/CAL2m5Fdf7h6aS5wuadXk_4epoK4yVSqB3107iY7oj6b49tkpJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Elastic Search API : heavy coupling design

2015-01-30 Thread Amaury Fages
Thank you for answering.

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.

2015-01-30 17:18 GMT+01:00 David Pilato :

> What is your version A?
> And version B?
>
> 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.
>
>
> --
> *David Pilato* | *Technical Advocate* | *Elasticsearch.com
> *
> @dadoonet  | @elasticsearchfr
>  | @scrutmydocs
> 
>
>
>
> Le 30 janv. 2015 à 15:42, Amaury Fages  a écrit :
>
> Hello everyone,
>
> 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 :
>
> 1) Wait for a solution from ES (in a reasonable time)
> 2) 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 ?
>
> Best regards,
>
> Amaury FAGES.
>
> --
> You received this message because you are subscribed to the Google Groups
> "elasticsearch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elasticsearch+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elasticsearch/b2e13fe4-1da4-4a76-8b03-4c0e553cd887%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "elasticsearch" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elasticsearch/hiOsFiPaZnY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elasticsearch+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elasticsearch/764D4229-6F7B-4435-92F3-3930F02601D9%40pilato.fr
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/CAL2m5Ff45K44yaqYBH2eNtyxBJ3OQi2b%2BZ5w99EfOW0iCdkQ6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Elastic Search API : heavy coupling design

2015-01-30 Thread David Pilato
What is your version A?
And version B?

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.


-- 
David Pilato | Technical Advocate | Elasticsearch.com
@dadoonet  | @elasticsearchfr 
 | @scrutmydocs 




> Le 30 janv. 2015 à 15:42, Amaury Fages  a écrit :
> 
> Hello everyone,
> 
> 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 :
> 
> 1) Wait for a solution from ES (in a reasonable time)
> 2) 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 ?
> 
> Best regards,
> 
> Amaury FAGES. 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "elasticsearch" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elasticsearch+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/elasticsearch/b2e13fe4-1da4-4a76-8b03-4c0e553cd887%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/764D4229-6F7B-4435-92F3-3930F02601D9%40pilato.fr.
For more options, visit https://groups.google.com/d/optout.


Elastic Search API : heavy coupling design

2015-01-30 Thread Amaury Fages
Hello everyone,

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 :

1) Wait for a solution from ES (in a reasonable time)
2) 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 ?

Best regards,

Amaury FAGES. 

-- 
You received this message because you are subscribed to the Google Groups 
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/b2e13fe4-1da4-4a76-8b03-4c0e553cd887%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.