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.
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
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.
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:
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.
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.
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:
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.
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.