[KYUUBI #4111] JDBC ExecuteStatement operation should contain operationLog

[yikf]

Why are the changes needed?

Close #4111, JDBC ExecuteStatement operation should contain operationLog

How was this patch tested?

• Add some test cases that check the changes thoroughly including negative and positive cases if possible

• Add screenshots for manual tests if appropriate

• Run test locally before make a pull request

[yikf]

cc @zhaomin1423

[zhaomin1423]

LGTM

[yaooqinn]

Hmm, isn't the error handled when an operation log is created?

[yaooqinn]

the original intentions are:

1. the operations that need operation logs shall implement getOperationLog
2. the client will only call fetching log for those operations which implement getOperationLog
3. the error raise only when the operation implements getOperationLog but fails to create the operation log file

[zhaomin1423]

the original intentions are:

1. the operations that need operation logs shall implement getOperationLog
2. the client will only call fetching log for those operations which implement getOperationLog
3. the error raise only when the operation implements getOperationLog but fails to create the operation log file

2 can't work well now.

[yikf]

Yeah, 2 can not work well；

End-user can fetch logs through OperationResource as well, The client will only can fetch log for those operations which implement getOperationLog seems impossible to limit?

[yaooqinn]

After this change, we can not determine whether the log is failed or just not implemented

[yaooqinn]

2 can't work well now.

This is by contract, these OperationResouce's clients shall be able to benefit from the current implementation too.

[yikf]

After this change, we can not determine whether the log is failed or just not implemented

Good point, Have a question is which of the following designs is more reasonable:

1. Fetch empty log if the operation don't implements getOperationLog
2. Have the contract, client will only call fetching log for those operations which implement getOperationLog

If 1, we can handle whether the log is failed or just not implemented;
if 2, we can handle this case according to this contract at client/jdbc engine side;

shall be able to benefit from the current implementation too.

What are the benefits? (sorry for I didn't know the previous design ) : )

[yaooqinn]

What are the benefits? (sorry for I didn't know the previous design ) : )

The benefits are what I described above for distinguishing errors with unimplemented.

The thrift and rest calls have no differences on both the log API and the backend operations. It's up to much higher level APIs(such as JDBC), or end-users, to do the error handling.

Currently, the meta operations are no operation logs and are executed synchronously. The rest call can also invoke these operations synchronously, which makes it has no chance to call log fetching

[yikf]

I fix this issue at jdbc engine side, please take a look if you find a moment, thanks @yaooqinn @turboFei @zhaomin1423

[turboFei]

thanks, merged to master