add TCC model to fescar, resolve conflicks (#582) #583

zhangthen · 2019-03-12T12:55:52Z

Integrated the TCC mode into seata.

codecov-io · 2019-03-12T12:59:08Z

Codecov Report

Merging #583 into develop will increase coverage by 0.06%.
The diff coverage is 19.84%.

@@              Coverage Diff              @@
##             develop     #583      +/-   ##
=============================================
+ Coverage      31.79%   31.85%   +0.06%     
- Complexity       798      863      +65     
=============================================
  Files            204      227      +23     
  Lines           8180     8817     +637     
  Branches         962     1060      +98     
=============================================
+ Hits            2601     2809     +208     
- Misses          5318     5695     +377     
- Partials         261      313      +52

Impacted Files	Coverage Δ	Complexity Δ
...lTransactionWithGlobalLockDataSourceBasicTest.java	`0% <ø> (ø)`	`0 <0> (ø)`	⬇️
...a/com/alibaba/fescar/test/DataSourceBasicTest.java	`0% <ø> (ø)`	`0 <0> (ø)`	⬇️
...main/java/com/alibaba/fescar/common/Constants.java	`0% <ø> (ø)`	`0 <0> (ø)`	⬇️
...ava/com/alibaba/fescar/rm/AbstractRMHandlerAT.java	`0% <ø> (ø)`	`0 <0> (ø)`	⬇️
...rc/main/java/com/alibaba/fescar/rm/RMClientAT.java	`0% <ø> (ø)`	`0 <0> (ø)`	⬇️
...ibaba/fescar/rm/tcc/remoting/parser/DubboUtil.java	`0% <0%> (ø)`	`0 <0> (?)`
.../rm/tcc/remoting/parser/SofaRpcRemotingParser.java	`0% <0%> (ø)`	`0 <0> (?)`
...libaba/fescar/rm/datasource/DataSourceManager.java	`0% <0%> (ø)`	`0 <0> (ø)`	⬇️
.../alibaba/fescar/rm/datasource/DataSourceProxy.java	`18.18% <0%> (-0.87%)`	`0 <0> (ø)`
...com/alibaba/fescar/common/util/ReflectionUtil.java	`0% <0%> (ø)`	`0 <0> (?)`
... and 60 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9040c42...bfb64a5. Read the comment docs.

skyesx

统一字段对齐风格，如BusinessActionContext 与其他对其风格不一致
TccResourceManager类名Tcc为小写，与其他不一致
Protocols 是否考虑使用常量定义而非枚举定义？这样以便于其他其他人员能在不修改fescar-tcc的基础上扩展实现
LocalTCCRemotingParser的getServiceDesc是否永远返回null,后续代码不起作用？
Tcc的Annotation放在fescar-spring里是否更好？
TC的Cacnel操作发起有可能先于实际业务的try的执行

github-ygy · 2019-03-13T02:29:04Z

统一字段对齐风格，如BusinessActionContext 与其他对其风格不一致

TccResourceManager类名Tcc为小写，与其他不一致

Protocols 是否考虑使用常量定义而非枚举定义？这样以便于其他其他人员能在不修改fescar-tcc的基础上扩展实现

LocalTCCRemotingParser的getServiceDesc是否永远返回null,后续代码不起作用？

Tcc的Annotation放在fescar-spring里是否更好？

TC的Cacnel操作发起有可能先于实际业务的try的执行

LocalTCCRemotingParser会判断类是否有LocalTcc注解，不会永远为null，
但是DefaultRemotingParser#parserRemotingServiceInfo为何不对null值做校验，
如果这块处理空数据不抛异常的话，建议这段代码可以合并，以parserRemotingServiceInfo方法返回空数据来做判断
protected boolean parserRemotingServiceInfo(Object bean, String beanName) { //是否是远程服务bean if(DefaultRemotingParser.get().isRemoting(bean, beanName)) { //解析remoting bean 信息 DefaultRemotingParser.get().parserRemotingServiceInfo(bean, beanName); return true; } return false; }
=>
protected boolean parserRemotingServiceInfo(Object bean, String beanName) { //是否是远程服务bean if (DefaultRemotingParser.get().parserRemotingServiceInfo(bean, beanName) != null) { return true; } return false; }

zhangthen · 2019-03-13T02:55:29Z

统一字段对齐风格，如BusinessActionContext 与其他对其风格不一致

TccResourceManager类名Tcc为小写，与其他不一致

Protocols 是否考虑使用常量定义而非枚举定义？这样以便于其他其他人员能在不修改fescar-tcc的基础上扩展实现

LocalTCCRemotingParser的getServiceDesc是否永远返回null,后续代码不起作用？

Tcc的Annotation放在fescar-spring里是否更好？

TC的Cacnel操作发起有可能先于实际业务的try的执行

@skyesx

“统一字段对齐风格，如BusinessActionContext 与其他对其风格不一致”，“TccResourceManager类名Tcc为小写，与其他不一致” ，已经改了；

“ Protocols 是否考虑使用常量定义而非枚举定义？这样以便于其他其他人员能在不修改fescar-tcc的基础上扩展实现” ，这个见仁见智吧，目前能枚举出来的RPC框架可能不会超过10个吧，我可以现在就把你能枚举出来的RPC框架加进去，虽然现在不一定会全部去支持，但这个枚举类被动的频率非常低；另外，为了保障和我们商业版的兼容性，这个枚举也不打算动；

“ LocalTCCRemotingParser的getServiceDesc是否永远返回null,后续代码不起作用？”，LocalTCCRemotingParser.getServiceDesc 不是永远返回null的，你可以跑一下TCC的 localtcc demo验证一下；

“Tcc的Annotation放在fescar-spring里是否更好？”，现在是fescar-spring依赖 fescar-tcc，把TCC的枚举移到 fescar-spring中的话，fescar-tcc里面就访问不到这些TCC的注解了；所以TCC的注解还是会放在fescar-tcc里面；不过后续fescar的代码库结构可以再调整一下，现在缺一个“fescar-api ”包来存储所有api性质的类；

“TC的Cacnel操作发起有可能先于实际业务的try的执行”，确实有这个问题，这是TCC的另外一个功能解决的问题，这次没开出来；

zhangthen · 2019-03-13T03:01:43Z

统一字段对齐风格，如BusinessActionContext 与其他对其风格不一致

TccResourceManager类名Tcc为小写，与其他不一致

Protocols 是否考虑使用常量定义而非枚举定义？这样以便于其他其他人员能在不修改fescar-tcc的基础上扩展实现

LocalTCCRemotingParser的getServiceDesc是否永远返回null,后续代码不起作用？

Tcc的Annotation放在fescar-spring里是否更好？

TC的Cacnel操作发起有可能先于实际业务的try的执行

LocalTCCRemotingParser会判断类是否有LocalTcc注解，不会永远为null，
但是DefaultRemotingParser#parserRemotingServiceInfo为何不对null值做校验，
如果这块处理空数据不抛异常的话，建议这段代码可以合并，以parserRemotingServiceInfo方法返回空数据来做判断
protected boolean parserRemotingServiceInfo(Object bean, String beanName) { //是否是远程服务bean if(DefaultRemotingParser.get().isRemoting(bean, beanName)) { //解析remoting bean 信息 DefaultRemotingParser.get().parserRemotingServiceInfo(bean, beanName); return true; } return false; }
=>
protected boolean parserRemotingServiceInfo(Object bean, String beanName) { //是否是远程服务bean if (DefaultRemotingParser.get().parserRemotingServiceInfo(bean, beanName) != null) { return true; } return false; }

@github-ygy

DefaultRemotingParser#parserRemotingServiceInfo 在被调用之前，会先调用 DefaultRemotingParser.get().isRemoting(bean, beanName)判断一下的，如果DefaultRemotingParser.get().isRemoting(bean, beanName)为true是不会发生你说的问题，如果为false也不会进入这段代码；所以你说的问题不存在；

不过我可以再在 DefaultRemotingParser#parserRemotingServiceInfo 做一次判断兜底。

github-ygy · 2019-03-13T03:05:37Z

统一字段对齐风格，如BusinessActionContext 与其他对其风格不一致

TccResourceManager类名Tcc为小写，与其他不一致

Protocols 是否考虑使用常量定义而非枚举定义？这样以便于其他其他人员能在不修改fescar-tcc的基础上扩展实现

LocalTCCRemotingParser的getServiceDesc是否永远返回null,后续代码不起作用？

Tcc的Annotation放在fescar-spring里是否更好？

TC的Cacnel操作发起有可能先于实际业务的try的执行

LocalTCCRemotingParser会判断类是否有LocalTcc注解，不会永远为null，
但是DefaultRemotingParser#parserRemotingServiceInfo为何不对null值做校验，
如果这块处理空数据不抛异常的话，建议这段代码可以合并，以parserRemotingServiceInfo方法返回空数据来做判断
protected boolean parserRemotingServiceInfo(Object bean, String beanName) { //是否是远程服务bean if(DefaultRemotingParser.get().isRemoting(bean, beanName)) { //解析remoting bean 信息 DefaultRemotingParser.get().parserRemotingServiceInfo(bean, beanName); return true; } return false; }
=>
protected boolean parserRemotingServiceInfo(Object bean, String beanName) { //是否是远程服务bean if (DefaultRemotingParser.get().parserRemotingServiceInfo(bean, beanName) != null) { return true; } return false; }

@github-ygy

DefaultRemotingParser#parserRemotingServiceInfo 在被调用之前，会先调用 DefaultRemotingParser.get().isRemoting(bean, beanName)判断一下的，如果DefaultRemotingParser.get().isRemoting(bean, beanName)为true是不会发生你说的问题，如果我false也不会进入这段代码；所以你说的问题不存在；

不过我可以再在 DefaultRemotingParser#parserRemotingServiceInfo 做一次判断兜底。

是的问题，不会出现，如果兜底判断了，可以把这段代码合并，因为后面的代码也会调用isRemoting

skyesx · 2019-03-13T15:09:03Z

“ Protocols 是否考虑使用常量定义而非枚举定义？这样以便于其他其他人员能在不修改fescar-tcc的基础上扩展实现”

这个见仁见智吧，目前能枚举出来的RPC框架可能不会超过10个吧，我可以现在就把你能枚举出来的RPC框架加进去，虽然现在不一定会全部去支持，但这个枚举类被动的频率非常低；另外，为了保障和我们商业版的兼容性，这个枚举也不打算动；
- 企业或许会有内部不开源的rpc框架，若枚举不打算变，建议增加一个表征用户自定义类型的枚举，用户需扩展时，就用这个枚举类型

“Tcc的Annotation放在fescar-spring里是否更好？”，

现在是fescar-spring依赖 fescar-tcc，把TCC的枚举移到 fescar-spring中的话，fescar-tcc里面就访问不到这些TCC的注解了；所以TCC的注解还是会放在fescar-tcc里面；不过后续fescar的代码库结构可以再调整一下，现在缺一个“fescar-api ”包来存储所有api性质的类；
- 现在是用了Annotation作为信息的载体，所以必须要在fescar-tcc里引入这个Annotation吧，如果有额外的载体是否annotation就可以迁移到fescar-spring。毕竟现有的@GlobalTransaction就是一个类似的做法，把Annotation仅作为用户便捷入口的封装形式，实际实现完全不依赖于Annotation，当然这个做法不一定最好，但若tcc做法不一致的话，会引起这个风格的不一致

jovany-wang

I just reviewed a little. 2 suggestions given you is here:

Do comment in English and comment interface clearly.
Format you code style with plugin?

jovany-wang · 2019-03-13T15:20:06Z

common/src/main/java/com/alibaba/fescar/common/loader/EnhancedServiceLoader.java

+     * @param <S>
+     * @return
+     */
+    public static <S> List<S> loadAll(Class<S> service){


public static <S> List<S> loadAll(Class<S> service) {

jovany-wang · 2019-03-13T15:20:45Z

common/src/main/java/com/alibaba/fescar/common/loader/EnhancedServiceLoader.java

@@ -100,6 +102,28 @@
        return loadFile(service, activateName, loader);
    }

+    /**
+     * 返回所有实现类实例


comment this in English.

@jovany-wang I will change it to English, but there were many Chinese comments in this file before.

jovany-wang · 2019-03-13T15:22:37Z

common/src/main/java/com/alibaba/fescar/common/loader/EnhancedServiceLoader.java

+     * @return
+     */
+    public static <S> List<S> loadAll(Class<S> service){
+        List<S> allInstances = new ArrayList<>();


List<S> allInstances = new ArrayList<>(); List<Class> allClazzs = getAllExtensionClass(service); if(!CollectionUtils.isEmpty(allClazzs)){ try { for(Class clazz : allClazzs){ allInstances.add(initInstance(service, clazz)); } } catch (Throwable t) { throw new EnhancedServiceNotFoundException(t); } } return allInstances;

zhangthen · 2019-03-14T02:58:19Z

2. Format you code style with plugin?

@jovany-wang

"Format you code style with plugin?" , This is already planned, I will use maven plugin to reformat all projects with p3c codestyle in next PR, There is a miss of automatic reformat mechanism now.

zhangthen · 2019-03-14T03:03:01Z

“ Protocols 是否考虑使用常量定义而非枚举定义？这样以便于其他其他人员能在不修改fescar-tcc的基础上扩展实现”

这个见仁见智吧，目前能枚举出来的RPC框架可能不会超过10个吧，我可以现在就把你能枚举出来的RPC框架加进去，虽然现在不一定会全部去支持，但这个枚举类被动的频率非常低；另外，为了保障和我们商业版的兼容性，这个枚举也不打算动；

企业或许会有内部不开源的rpc框架，若枚举不打算变，建议增加一个表征用户自定义类型的枚举，用户需扩展时，就用这个枚举类型

“Tcc的Annotation放在fescar-spring里是否更好？”，

现在是fescar-spring依赖 fescar-tcc，把TCC的枚举移到 fescar-spring中的话，fescar-tcc里面就访问不到这些TCC的注解了；所以TCC的注解还是会放在fescar-tcc里面；不过后续fescar的代码库结构可以再调整一下，现在缺一个“fescar-api ”包来存储所有api性质的类；

现在是用了Annotation作为信息的载体，所以必须要在fescar-tcc里引入这个Annotation吧，如果有额外的载体是否annotation就可以迁移到fescar-spring。毕竟现有的@GlobalTransaction就是一个类似的做法，把Annotation仅作为用户便捷入口的封装形式，实际实现完全不依赖于Annotation，当然这个做法不一定最好，但若tcc做法不一致的话，会引起这个风格的不一致

@skyesx 我在后面的PR中，重新对工程结构进行重排，现在缺一个类似“fescar-api”的包放所有api，把Annotation放在 fescar-spring也不是一个最优方式

github-ygy

BusinessActionContextParameter#isShardingParam
how it work ？

github-ygy

i have some questions about actionName（TCCResource)

github-ygy · 2019-03-14T12:39:39Z

tcc/src/main/java/com/alibaba/fescar/rm/tcc/remoting/parser/DefaultRemotingParser.java

+                    if(twoPhaseBusinessAction != null){
+                        //一阶段方法, 提取TCC 服务 信息，注册TCC资源
+                        TCCResource tccResource = new TCCResource();
+                        tccResource.setActionName(twoPhaseBusinessAction.name());


actionName的设定需要唯一，由于依赖的dubbo的jar可能来自不同团队，极有可能冲突，我们是不是可以把这个类名也加进去标记唯一例如:com.alibaba.fescar.samples.tcc.dubbo.action.TccActionOne#+twoPhaseBusinessAction.name() 来标记整个类唯一即可。
另外对于actionName的唯一设置，我们是不是该加一个校验？

actionName的设定需要唯一，由于依赖的dubbo的jar可能来自不同团队，极有可能冲突，我们是不是可以把这个类名也加进去标记唯一例如:com.alibaba.fescar.samples.tcc.dubbo.action.TccActionOne#+twoPhaseBusinessAction.name() 来标记整个类唯一即可。
另外对于actionName的唯一设置，我们是不是该加一个校验？

@github-ygy

确实会有actionName冲突的可能，但是在开源版里面我们没把功能做的很强；

在我们商业版中，会把 interface和version 都拼接到 actionName中，这样才能尽量保证唯一；
你说的只拼接interface是不够的，以dubbo为例，还会存在interface相同但是version不同的情况；
我们商业版在服务端也对资源进行了冲突的校验，但是TCC开源版第一个版只打算先把最基本的功能开出去，不打算一次性把所有功能全部开出去。

github-ygy · 2019-03-15T01:52:39Z

tcc/src/main/java/com/alibaba/fescar/rm/tcc/TCCResourceManager.java

+import com.alibaba.fescar.core.exception.TransactionExceptionCode;
+import com.alibaba.fescar.core.model.BranchStatus;
+import com.alibaba.fescar.core.model.BranchType;
+import com.alibaba.fescar.core.model.Resource;


better to remove unnecessary import class

zhangthen · 2019-03-15T02:17:45Z

BusinessActionContextParameter#isShardingParam
how it work ？

目前，当前开源的版本功能比较简单，这个属性是分库分表时才会用到的，当前版本还没用到；

slievrly · 2019-03-16T10:43:27Z

tcc/src/main/java/com/alibaba/fescar/rm/tcc/TCCResourceManager.java

+			}else {
+				result = (boolean) ret;
+			}
+			return result ? BranchStatus.PhaseTwo_Committed:BranchStatus.PhaseTwo_CommitFailed_Retryable;


when result type is TwoPhaseResult and ret.isSuccess()=false , just return PhaseTwo_CommitFailed_Retryable, why not print TwoPhaseResult#msg to check problem？

slievrly · 2019-03-16T10:51:18Z

tcc/src/main/java/com/alibaba/fescar/rm/tcc/remoting/parser/DefaultRemotingParser.java

+        //init all resource managers
+        List<RemotingParser> remotingParsers = EnhancedServiceLoader.loadAll(RemotingParser.class);
+        if(CollectionUtils.isNotEmpty(remotingParsers)){
+            for(RemotingParser rp : remotingParsers){


addAll or allRemotingParsers= remotingParsers?

slievrly · 2019-03-16T10:53:47Z

tcc/src/main/java/com/alibaba/fescar/rm/tcc/remoting/RemotingParser.java

+     * @return boolean boolean
+     * @throws FrameworkException the framework exception
+     */
+    public boolean isRemoting(Object bean, String beanName) throws FrameworkException;


remove all interface method public

@slievrly interface 中的方法默认是public的，加public和不加没什么区别；我们这边没听说一定要把interface中方法的public去掉的的要求，阿里集团那边对这个有明确要求吗？

I am not Alibaba's employee, @slievrly is.

slievrly · 2019-03-16T13:42:33Z

spring/src/main/java/com/alibaba/fescar/spring/annotation/GlobalTransactionScanner.java

+     * @param beanName the bean name
+     * @return boolean boolean
+     */
+    protected boolean isTccAutoProxy(Object bean, String beanName){


can move to other class（eg：TCCUtils#isTccAutoProxy(Object bean, String beanName，ApplicationContext applicationContext)）

skyesx · 2019-03-17T01:26:37Z

on the issue of annotation, i think we should get agreement as soon as possible. because it's user interface ， if we not change now，with later refactor, user code have to change too.

对于注解的位置问题，我觉得应该尽快统一思路，因为这是用户接口，若现在不改，后续要重构的话，用户代码也需要进行直接的变动

@slievrly @zhangthen

slievrly · 2019-03-17T06:47:01Z

tcc/src/main/java/com/alibaba/fescar/rm/tcc/interceptor/ActionInterceptorHandler.java

+        //set the parameter whose type is BusinessActionContext
+        Class<?>[] types = method.getParameterTypes();
+        int argIndex = 0;
+        for (Class<?> cls : types) {


why need BIZ specifies the parameter location instead of placing it at the end?

BusinessActionContext param

why need BIZ specifies the parameter location instead of placing it at the end?

@slievrly We don't specify the location of BusinessActionContext , user can put it anywhere.

slievrly · 2019-03-17T06:55:18Z

on the issue of annotation, i think we should get agreement as soon as possible. because it's user interface ， if we not change now，with later refactor, user code have to change too.

对于注解的位置问题，我觉得应该尽快统一思路，因为这是用户接口，若现在不改，后续要重构的话，用户代码也需要进行直接的变动

@slievrly @zhangthen

I agree with this point, the annotation is an extension built on the api.

CLAassistant · 2019-03-19T04:13:56Z

All committers have signed the CLA.

slievrly · 2019-03-19T04:33:41Z

tcc/pom.xml

+        <dependency>
+            <groupId>junit</groupId>
+            <artifactId>junit</artifactId>
+            <version>${junit.version}</version>


remove version

sharajava

It's Okey to me.

add TCC model to fescar, resolve conflicks (#582)

635e3da

slievrly requested review from skyesx, github-ygy, jovany-wang, slievrly and sharajava March 12, 2019 12:57

skyesx suggested changes Mar 12, 2019

View reviewed changes

add feature tcc,fix review problems (#585)

d3357d5

jovany-wang suggested changes Mar 13, 2019

View reviewed changes

fix review problems (#596)

b0039c9

github-ygy reviewed Mar 14, 2019

View reviewed changes

github-ygy suggested changes Mar 14, 2019

View reviewed changes

github-ygy suggested changes Mar 15, 2019

View reviewed changes

remove unused imports (#603)

4e7b5ce

github-ygy approved these changes Mar 15, 2019

View reviewed changes

fix review problem (#607)

d4d6a80

slievrly reviewed Mar 16, 2019

View reviewed changes

slievrly reviewed Mar 17, 2019

View reviewed changes

zhangthen added 2 commits March 18, 2019 13:37

fix review problems (#620)

c8f777a

Fix conflict (#621)

28f894c

skyesx approved these changes Mar 19, 2019

View reviewed changes

zhangthen and others added 2 commits March 19, 2019 11:51

Fix conflict of config/pom.xml (#622)

5a68e52

Merge branch 'develop' into feature_tcc_temp

bfb64a5

slievrly reviewed Mar 19, 2019

View reviewed changes

slievrly approved these changes Mar 19, 2019

View reviewed changes

sharajava approved these changes Mar 19, 2019

View reviewed changes

slievrly merged commit c421ee0 into develop Mar 19, 2019

fescar-robot mentioned this pull request Mar 22, 2019

[WeeklyReport] Weekly report for FESCAR 2019-3-15 to 2019-3-22 #645

Closed

slievrly deleted the feature_tcc_temp branch March 26, 2019 03:01

wangliang181230 added this to the 0.4.* milestone Aug 9, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

add TCC model to fescar, resolve conflicks (#582) #583

add TCC model to fescar, resolve conflicks (#582) #583

zhangthen commented Mar 12, 2019 •

edited

Loading

codecov-io commented Mar 12, 2019 •

edited

Loading

skyesx left a comment •

edited

Loading

github-ygy commented Mar 13, 2019

zhangthen commented Mar 13, 2019 •

edited

Loading

zhangthen commented Mar 13, 2019 •

edited

Loading

github-ygy commented Mar 13, 2019

skyesx commented Mar 13, 2019

jovany-wang left a comment

jovany-wang Mar 13, 2019

jovany-wang Mar 13, 2019

zhangthen Mar 14, 2019

jovany-wang Mar 13, 2019

zhangthen commented Mar 14, 2019 •

edited

Loading

zhangthen commented Mar 14, 2019

github-ygy left a comment

github-ygy left a comment

github-ygy Mar 14, 2019 •

edited

Loading

zhangthen Mar 15, 2019

github-ygy Mar 15, 2019

zhangthen commented Mar 15, 2019

slievrly Mar 16, 2019

slievrly Mar 16, 2019

slievrly Mar 16, 2019

zhangthen Mar 16, 2019 •

edited

Loading

skyesx Mar 17, 2019

slievrly Mar 16, 2019

skyesx commented Mar 17, 2019

slievrly Mar 17, 2019

slievrly Mar 17, 2019

zhangthen Mar 18, 2019

slievrly commented Mar 17, 2019

CLAassistant commented Mar 19, 2019 •

edited

Loading

slievrly Mar 19, 2019

sharajava left a comment

add TCC model to fescar, resolve conflicks (#582) #583

add TCC model to fescar, resolve conflicks (#582) #583

Conversation

zhangthen commented Mar 12, 2019 • edited Loading

codecov-io commented Mar 12, 2019 • edited Loading

Codecov Report

skyesx left a comment • edited Loading

Choose a reason for hiding this comment

github-ygy commented Mar 13, 2019

zhangthen commented Mar 13, 2019 • edited Loading

zhangthen commented Mar 13, 2019 • edited Loading

github-ygy commented Mar 13, 2019

skyesx commented Mar 13, 2019

jovany-wang left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zhangthen commented Mar 14, 2019 • edited Loading

zhangthen commented Mar 14, 2019

github-ygy left a comment

Choose a reason for hiding this comment

github-ygy left a comment

Choose a reason for hiding this comment

github-ygy Mar 14, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zhangthen commented Mar 15, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zhangthen Mar 16, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

skyesx commented Mar 17, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

slievrly commented Mar 17, 2019

CLAassistant commented Mar 19, 2019 • edited Loading

Choose a reason for hiding this comment

sharajava left a comment

Choose a reason for hiding this comment

zhangthen commented Mar 12, 2019 •

edited

Loading

codecov-io commented Mar 12, 2019 •

edited

Loading

skyesx left a comment •

edited

Loading

zhangthen commented Mar 13, 2019 •

edited

Loading

zhangthen commented Mar 13, 2019 •

edited

Loading

zhangthen commented Mar 14, 2019 •

edited

Loading

github-ygy Mar 14, 2019 •

edited

Loading

zhangthen Mar 16, 2019 •

edited

Loading

CLAassistant commented Mar 19, 2019 •

edited

Loading