Massive Java client API breakages in master

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Massive Java client API breakages in master

Michael Klishin
Dear ElasticSearch maintainers, please reconsider the following changes:


Not only they break *every single app* that uses the Java client, it
also makes a lot of documentation and code examples around the Web
irrelevant, all at once.

I won't comment on whether sticking to beans-like setters and getters
in a DSL is a good idea but completely breaking existing projects and making a lot
of examples irrelevant doesn't sound like a price worth paying for
more standard method names.

I believe that the old API should be kept around for at least a few releases, marked as @deprecated, but not removed overnight.

Thank you.
--
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Massive Java client API breakages in master

Itamar Syn-Hershko
I'm actually in favor of this change. Adding is/get/set prefix is merely a breaking change, it will just throw some compilation errors.

I concur they should have went through a deprecation phase, but as both options were already there for most usages, I think once the change was made its OK to leave it that way


On Fri, Feb 22, 2013 at 1:29 PM, Michael Klishin <[hidden email]> wrote:
Dear ElasticSearch maintainers, please reconsider the following changes:


Not only they break *every single app* that uses the Java client, it
also makes a lot of documentation and code examples around the Web
irrelevant, all at once.

I won't comment on whether sticking to beans-like setters and getters
in a DSL is a good idea but completely breaking existing projects and making a lot
of examples irrelevant doesn't sound like a price worth paying for
more standard method names.

I believe that the old API should be kept around for at least a few releases, marked as @deprecated, but not removed overnight.

Thank you.
--
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Massive Java client API breakages in master

Oliver B. Fischer
In reply to this post by Michael Klishin
Michael,

you are absolutely right. Such easy refactorings in a public API should
never break depending clients. That is the reason why we have the
@deprecated stuff.

Bye,

Oliver

On 02/22/2013 12:29 PM, Michael Klishin wrote:

> Dear ElasticSearch maintainers, please reconsider the following changes:
>
> https://github.com/elasticsearch/elasticsearch/commit/cc83c2f848be69a77f1275fe1ff5363dcdd4c955
>
> Not only they break *every single app* that uses the Java client, it
> also makes a lot of documentation and code examples around the Web
> irrelevant, all at once.
>
> I won't comment on whether sticking to beans-like setters and getters
> in a DSL is a good idea but completely breaking existing projects and
> making a lot
> of examples irrelevant doesn't sound like a price worth paying for
> more standard method names.
>
> I believe that the old API should be kept around for at least a few
> releases, marked as @deprecated, but not removed overnight.
>
> Thank you.
> --
> MK
>
> http://github.com/michaelklishin
> http://twitter.com/michaelklishin
>
> --
> 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 [hidden email].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.


Reply | Threaded
Open this post in threaded view
|

Re: Massive Java client API breakages in master

kimchy
Administrator
Hey, I commented on the issue itself. The idea was to remove the duplication of getXXX and xxx methods we have on response objects, and just stay with getXXX, and this is what we did. We went a step further and changed the XXXRequest classes to use setters, which we shouldn't have (the XXXRequestBuilders are there to use the setter notion). We will revert back the XXXRequest changes.

On Feb 22, 2013, at 2:15 PM, Oliver B. Fischer <[hidden email]> wrote:

> Michael,
>
> you are absolutely right. Such easy refactorings in a public API should never break depending clients. That is the reason why we have the @deprecated stuff.
>
> Bye,
>
> Oliver
>
> On 02/22/2013 12:29 PM, Michael Klishin wrote:
>> Dear ElasticSearch maintainers, please reconsider the following changes:
>>
>> https://github.com/elasticsearch/elasticsearch/commit/cc83c2f848be69a77f1275fe1ff5363dcdd4c955
>>
>> Not only they break *every single app* that uses the Java client, it
>> also makes a lot of documentation and code examples around the Web
>> irrelevant, all at once.
>>
>> I won't comment on whether sticking to beans-like setters and getters
>> in a DSL is a good idea but completely breaking existing projects and
>> making a lot
>> of examples irrelevant doesn't sound like a price worth paying for
>> more standard method names.
>>
>> I believe that the old API should be kept around for at least a few
>> releases, marked as @deprecated, but not removed overnight.
>>
>> Thank you.
>> --
>> MK
>>
>> http://github.com/michaelklishin
>> http://twitter.com/michaelklishin
>>
>> --
>> 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 [hidden email].
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> --
> 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 [hidden email].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.