Skip to content

Use NodeType enum instead of Strings#6377

Merged
b-slim merged 7 commits intoapache:masterfrom
metamx:NodeType-enum
Oct 15, 2018
Merged

Use NodeType enum instead of Strings#6377
b-slim merged 7 commits intoapache:masterfrom
metamx:NodeType-enum

Conversation

@leventov
Copy link
Copy Markdown
Member

For type safety and code readability.

*/
public enum NodeType
{
coordinator,
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think all these enum values in uppercase would be better.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

See the comment in the line 23. These names and the fact that Jackson serializes enum constants to their names as strings allows this PR to be non-breaking.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

You can customize this with a @JsonValue annotation: see LongEncodingStrategy for an example.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Right, changed.

DruidNodeDiscoveryProvider.NODE_TYPE_ROUTER,
DruidNodeDiscoveryProvider.NODE_TYPE_MM
);
private static final List<NodeType> NODE_TYPES = Arrays.asList(NodeType.values());
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

BTW not sure about this, if coordinator was skipped on purpose or by mistake. See #5099 (comment). @jon-wei

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Reverted according to #5099 (comment)

@jihoonson
Copy link
Copy Markdown
Contributor

There is something similar to this called ServerType. Can we merge that with NodeType?

@leventov
Copy link
Copy Markdown
Member Author

@jihoonson see #6384, I think this is not reasonable unless we are willing to break JSON APIs.

@leventov
Copy link
Copy Markdown
Member Author

leventov commented Oct 8, 2018

@himanshug could you please take a look?

@himanshug
Copy link
Copy Markdown
Contributor

This looks like a trivial change. But, have you tested this on a running cluster to ensure it doesn't break anything?

LGTM otherwise.

@leventov
Copy link
Copy Markdown
Member Author

@himanshug we never test any changes before merging into master. Integration tests are supposed to test inter-node and ZK communications.

@himanshug
Copy link
Copy Markdown
Contributor

I wish I was as confident about integration tests. In general, I think I try and test everything at least in a toy cluster when sending the PR and saying it was done from my side. Even that doesn't catch all problems but gives me as PR author some confidence.

@himanshug
Copy link
Copy Markdown
Contributor

that said, this PR looks pretty trivial and it is likely that integration env will cover it but it is usually nice to test such changes.

@leventov
Copy link
Copy Markdown
Member Author

I think I try and test everything at least in a toy cluster when sending the PR and saying it was done from my side.

I think this is inefficient. A PR like this one is normally done in less than one hour, while creating a distribution, a test cluster, and testing the new code reasonably is much more work to do. The release baking process with release candidates should provide such testing "in batch" for all PRs that are included in a specific release.

@himanshug
Copy link
Copy Markdown
Contributor

himanshug commented Oct 11, 2018

my two cents...
I certainly don't expect all PRs to go through real cluster testing except the ones that change cluster coordination or other things that are hard to unit test etc.
Release baking process is great but doesn't have to be a substitute for testing our own code. Also, by that time a lot of PRs pile on top of each other and maybe harder to pinpoint exactly which PR caused the issue. So, it is again nice to do some testing upfront and not wait for release being cut.

Personally, I feel more confident with the work when it is tested. Code reviews catch some bugs but testing the change is always great when possible :) .

@b-slim
Copy link
Copy Markdown
Contributor

b-slim commented Oct 15, 2018

Assuming this pr had +1 from @himanshug I think it is a good pr so let's get it in

@b-slim b-slim merged commit aa121da into apache:master Oct 15, 2018
QiuMM pushed a commit to QiuMM/druid that referenced this pull request Oct 15, 2018
jihoonson pushed a commit that referenced this pull request Oct 15, 2018
gianm pushed a commit to implydata/druid-public that referenced this pull request Dec 19, 2018
* Use NodeType enum instead of Strings

* Make NodeType constants uppercase

* Fix CommonCacheNotifier and NodeType/ServerType comments

* Reconsidering comment

* Fix import

* Add a comment to CommonCacheNotifier.NODE_TYPES
@jon-wei jon-wei added this to the 0.14.0 milestone Feb 20, 2019
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.

8 participants