-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
[core] Fix checkstyle for Core miscellaneous #901
[core] Fix checkstyle for Core miscellaneous #901
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just one important revert for compatibility and a couple of nit-picks about private
vs protected
. Only the DB properties var really needs addressing. The others shouldn't really affect anyone.
@Override | ||
protected StringBuilder initialValue() { | ||
return new StringBuilder(); | ||
} | ||
}; | ||
|
||
static StringBuilder getStringBuilder() { | ||
private static StringBuilder getStringBuilder() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super nit-picky but if anyone had their own code that was calling this from within the package or their own sublass then it would be a breaking change. Probably not a big deal at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also would increment the copyright :)
/** | ||
* Properties for configuring this DB. | ||
*/ | ||
private Properties properties = new Properties(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one needs stay the same _p
name so implementers don't see their code break. And protected
instead of private
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't leave _p since that is not an allowed variable name by checkstyle. I don't see a way around this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can provide a custom checkstyle config with the project. It's annoying but better to maintain compatibility than worry about styling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok thats fair I'll see what I can do. I think there is a Suppress annotation way to handle just this line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So looking at this closer, there already exist get/set property methods so that should encapsulate the _p variable and allow us to change the name. If people were relying on the _p variable they should have been using the get/set methods.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, yeah I guess since none of the existing DB's use it directly and it's a tiny API change it'd be fine. We should just make a big note of it in the release notes.
* @param result A HashMap of field/value pairs for the result | ||
* @return The result of the operation. | ||
*/ | ||
public abstract Status read(String table, String key, Set<String> fields, HashMap<String, ByteIterator> result); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be nice to change the HashMap
to a Map
since that shouldn't break the API and be consistent with Set
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to leave this to another issue. This requires changing all the implementations to match the method signature of the abstract method.
public static final String SIMULATE_DELAY = "gbudb.delays"; | ||
public static final String SIMULATE_DELAY_DEFAULT = "200,1000,10000,50000,100000"; | ||
private long[] delays; | ||
private static final ReadWriteLock DB_ACCESS = new ReentrantReadWriteLock(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nother nit regarding the privatization of these two. Shouldn't be anyone using them but may be good to set them to protected
just to be safe.
} | ||
private long len; | ||
private InputStream ins; | ||
private long off; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nother nit, maybe protected
just to be safe.
String str; | ||
int off; | ||
private String str; | ||
private int off; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nother nit, protected
@@ -0,0 +1,22 @@ | |||
/* | |||
* Copyright (c) 2015 - 2016 YCSB contributors. All rights reserved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2015 - 2017
:)
@manolama Thanks for the review! I'll update it tomorrow most likely. |
9007cd8
to
5bada1e
Compare
5bada1e
to
90ab752
Compare
@manolama Updated the headers and fixed the getStringBuilder method to be protected. A few of the changes I didn't make since they made checkstyle very unhappy.
The comment about HashMap -> Map
My thought is that we should break compatibility and enforce checkstyle so it can't happen again. Right now we are not enforcing at all which makes it hard to even guarantee compatibility. |
Thanks @manolama! |
Relates to #895