Massive Java client API breakages in master

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://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 elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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 <
michael.s.klishin@gmail.com> 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 elasticsearch+unsubscribe@googlegroups.com.
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 elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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 elasticsearch+unsubscribe@googlegroups.com.
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 elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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 mailsink@swe-blog.net 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 elasticsearch+unsubscribe@googlegroups.com.
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 elasticsearch+unsubscribe@googlegroups.com.
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 elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.