sandynz commented on pull request #16036:
URL: https://github.com/apache/shardingsphere/pull/16036#issuecomment-1067672513
> How about split the pair as updated map and new collection? If the key is
null, it means there are not original config, which should belong to new
collection.
My investigation:
It's possible to do it, but the code might be more complicated than before.
Current code snippet:
```
private Optional<JobConfiguration> createJobConfig(final
StartScalingEvent event) {
//...
for (Pair<YamlRuleConfiguration, YamlRuleConfiguration> each :
groupSourceTargetRuleConfigsByType(sourceRootConfig.getRules(),
targetRootConfig.getRules())) {
//...
}
private Collection<Pair<YamlRuleConfiguration, YamlRuleConfiguration>>
groupSourceTargetRuleConfigsByType(final Collection<YamlRuleConfiguration>
sourceRules,
final Collection<YamlRuleConfiguration>
targetRules) {
//...
}
```
Currently, `groupSourceTargetRuleConfigsByType` method return unified
`Collection<Pair>`, and `createJobConfig` method just need one `for` loop.
If we split pairs to updated map and new collection, possible changes:
1. Split `groupSourceTargetRuleConfigsByType` method to `2` methods, one
return `Map` and another return `Collection<ruleConfig>`.
2. In `createJobConfig`, add another `for` loop to iterate
`Collection<ruleConfig>`.
3. In `createJobConfig`, in order to reuse the code of `for` loop, we need
to extract it into a new method.
It might be not worth to do it.
Another consideration, pair and tuple are basic data structrue in some
programming languages, they're useful sometimes.
So I think it's better to keep pair in project when it's needed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
