GEODE-6027: refactor updateClusterConfig#2825
GEODE-6027: refactor updateClusterConfig#2825pdxrunner wants to merge 1 commit intoapache:developfrom
Conversation
- Add ResultModel parameter - change from void return to boolean
|
@aditya87 @Petahhh FYI on this PR |
| @Override | ||
| public void updateClusterConfig(String group, CacheConfig cacheConfig, Object element) { | ||
| public boolean updateClusterConfig(String group, CacheConfig cacheConfig, Object element, | ||
| ResultModel resultModel) { |
There was a problem hiding this comment.
is this resultModel used in any implementation?
There was a problem hiding this comment.
Not yet. We wanted to due the refactoring of updateClusterConfig as an initial PR. Individual commands will use this as they are refactored to use SingleGfshCommand. Initial work on refactoring AlterAsyncEventQueue is what prompted this change.
There was a problem hiding this comment.
Hmmm, yes it may well be a premature refactor that we don't really need.
| .stream() | ||
| .filter(regionConfig -> regionConfig.getName().equals(newCacheElement.getRegionName())) | ||
| .forEach(regionConfig -> regionConfig.getCustomRegionElements().add(newCacheElement)); | ||
| return true; |
There was a problem hiding this comment.
where is the return value used?
There was a problem hiding this comment.
The return value is used in CommandExecutor.invokeCommand. Individual command classes that override updateClusterConfig will return true or false to indicate whether the configuration was updated or not (or possibly throw an exception if an error occurred updating the configuration).
|
@pdxrunner is this PR going to see any more effort or should it be closed? |
Thanks for pinging me on this. I should have closed it out when I superseded it with #2846 |
4 participants
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:
Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?
Has your PR been rebased against the latest commit within the target branch (typically
develop)?Is your initial contribution a single, squashed commit?
Does
gradlew buildrun cleanly?Have you written or updated unit tests to verify your changes?
If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to dev@geode.apache.org.