add apollo datasource extension #46
Conversation
|
|
Codecov Report
@@ Coverage Diff @@
## master #46 +/- ##
============================================
- Coverage 45.86% 45.68% -0.19%
+ Complexity 552 550 -2
============================================
Files 113 113
Lines 3800 3800
Branches 533 533
============================================
- Hits 1743 1736 -7
- Misses 1846 1851 +5
- Partials 211 213 +2
Continue to review full report at Codecov.
|
| //change is never null because the listener will only notify for this key | ||
| if (change != null) { | ||
| RecordLog.info( | ||
| String.format("[ApolloDataSource] Received config changes: %s", changeEvent.getChange(flowRulesKey))); |
There was a problem hiding this comment.
changeEvent.getChange(flowRulesKey) 与前面重复，可替换为 change
| RecordLog.info( | ||
| String.format("[ApolloDataSource] Received config changes: %s", changeEvent.getChange(flowRulesKey))); | ||
| } | ||
| loadAndUpdateRules(); |
There was a problem hiding this comment.
这个地方有一个疑问：我看了一下 ConfigChange 的定义，貌似可以直接从中获取 newValue，然后进行更新；而 loadAndUpdateRules 方法中调用了 loadConfig 方法，后者实际调用 readSource 方法主动读取数据，这会不会导致多读一次？
There was a problem hiding this comment.
ConfigChange中确实是可以拿到newValue的，不过ConfigChange有多种change type：ADDED, MODIFIED和DELETED。
对DELETED类型，如果直接用newValue其实是空的，所以再走一次loadAndUpdateRules可以确保默认值会被用到。
对于Apollo而言，只有ConfigService.getConfig会触发网络调用，对于config.getProperty始终是从内存中读取配置的，所以从内存中再读取一次也是没有性能影响的，加之上述的defaultValue逻辑，所以选择了复用loadAndUpdateRules。
|
Thanks for your contribution! 👍 |
Describe what this PR does / why we need it
Add Apollo datasource extension.
Does this pull request fix one issue?
Closes #42
Describe how you did it
See ApolloDataSource.java
Describe how to verify it
See ApolloDataSourceDemo.java
Special notes for reviews