Skip to content

Remove NodeBuilder #15354

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 11, 2015
Merged

Remove NodeBuilder #15354

merged 1 commit into from
Dec 11, 2015

Conversation

rjernst
Copy link
Member

@rjernst rjernst commented Dec 10, 2015

The NodeBuilder is currently used to construct a Node. However, this is
really just yet-another-builder that wraps around a Settings.Builder
witha couple convenience methods. But there are very few uses of these
convenience methods. This change removes NodeBuilder, in favor of just
using the Node constructor.

The NodeBuilder is currently used to construct a Node. However, this is
really just yet-another-builder that wraps around a Settings.Builder
witha couple convenience methods. But there are very few uses of these
convenience methods.  This change removes NodeBuilder, in favor of just
using the Node constructor.
@@ -31,11 +31,11 @@
public static void main(String[] args) {
long OPERATIONS = SizeValue.parseSizeValue("300k").singles();

Node node = NodeBuilder.nodeBuilder().node();
Node node = new Node(Settings.EMPTY);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.start() missing

@ywelsch
Copy link
Contributor

ywelsch commented Dec 10, 2015

Left some minor comments (missing start() calls and typo), o.w. LGTM.

@s1monw
Copy link
Contributor

s1monw commented Dec 10, 2015

+1

@jasontedor
Copy link
Member

I'm in favor of this change, but not in favor of making a change that will break compilation of client code in a minor release (this is currently labeled v2.2.0).

@rjernst
Copy link
Member Author

rjernst commented Dec 10, 2015

@jasontedor NodeBuilder has always been an internal API. The fact that some users (who embed ES) use it instead of the Node constructor is not a reason we should hold back internal refactoring. Users who embed ES are advanced enough that they can update to use the Node constructor.

@rjernst rjernst removed the v2.2.0 label Dec 11, 2015
@rjernst
Copy link
Member Author

rjernst commented Dec 11, 2015

I removed the 2.2 label, and opened an issue (#15383) to change the docs so constructing an in memory Node is never recommended.

rjernst added a commit that referenced this pull request Dec 11, 2015
@rjernst rjernst merged commit 93de1ed into elastic:master Dec 11, 2015
@rjernst rjernst deleted the just_node branch December 11, 2015 03:19
@s1monw
Copy link
Contributor

s1monw commented Dec 11, 2015

I'm in favor of this change, but not in favor of making a change that will break compilation of client code in a minor release (this is currently labeled v2.2.0).

Since we are in java you have to recompile your client code anyway so the compiler will tell you what's going on. This is a great way to move on with APIs - when I am in the situation I was always happy to see a hard break to make the changes early and often.

@clintongormley
Copy link
Contributor

@rjernst can we have a note in the breaking changes docs please

@s1monw
Copy link
Contributor

s1monw commented Dec 11, 2015

@rjernst can we have a note in the breaking changes docs please

is this necessary? It's unsupported really and a Java API

@dadoonet
Copy link
Member

Well. It has always been documented in the Java API doc. So that makes it a bit "official" IMO.

@bleskes
Copy link
Contributor

bleskes commented Dec 11, 2015

It's how we now officially communicate on how to start a client. https://www.elastic.co/guide/en/elasticsearch/client/java-api/current/node-client.html

+1 on clear messaging as to why we are changing it - to me, breaking changes feel natural.

@mikemccand
Copy link
Contributor

+1 to freely break this in 2.x and explain why in the breaking changes docs: javac makes it completely clear to these very expert users on upgrade that they need to use the Node constructor instead.

@bleskes
Copy link
Contributor

bleskes commented Dec 11, 2015

these very expert users

I think this is the source of where people have different feelings. These are not expert settings - it's what we recommend on our website and many Java people use. I'm totally +1 with changing that (on 3.0 I would go as far as not treating this as a client at all). We should clear document this, explain why and offer people an alternative.

pickypg added a commit to pickypg/elasticsearch-groovy that referenced this pull request Feb 7, 2016
@1ambda
Copy link

1ambda commented Nov 7, 2016

I think this is missing in 5.0 API breaking changes.

https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking-changes-5.0.html

@clintongormley
Copy link
Contributor

I think this is missing in 5.0 API breaking changes.

True. @rjernst could you add to the breaking changes please?

@rjernst
Copy link
Member Author

rjernst commented Nov 7, 2016

Added:
5.x: 71bc4c6
5.0: bc5d7a9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants