Closed zklgame closed 10 months ago
Attention: 165 lines
in your changes are missing coverage. Please review.
Comparison is base (
1c7a044
) 63.11% compared to head (42e94ae
) 62.96%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
This refactor uses a single doProcessLocalQueueCommandsAndMessagesTx
method to handle the logic for both updateWaitUntil and processLocalQueueMessages. Compared to the proposal in https://github.com/xdblab/xdb/pull/63#pullrequestreview-1697935884, the pros and cons of this refactor are:
In terms of functionality, these two methods can achieve the same results and performance because they both update the related rows in tables only once.
@longquanzheng What's your preference now?
This refactor uses a single
doProcessLocalQueueCommandsAndMessagesTx
method to handle the logic for both updateWaitUntil and processLocalQueueMessages. Compared to the proposal in #63 (review), the pros and cons of this refactor are:
- pros: highly resuse the codes and reduce maintainance effort for related logic.
- cons: might not as straightforward as the other one and sacrifice some readability.
In terms of functionality, these two methods can achieve the same results and performance because they both update the related rows in tables only once.
@longquanzheng What's your preference now?
Yeah, it's indeed a better/improved version than your previous one, and technically the same perf as what I proposed. I can clearly see the more code reuse than what I proposed:
SelectProcessExecutionForUpdate
/ UpdateProcessExecution
SelectAsyncStateExecutionForUpdate
/ UpdateAsyncStateExecution
And as you pointed out the readability:
request.ProcessLocalQueueCommandsAndTryConsumeRequest != nil
to branch which actually brings quite some complexity to understandProcessLocalQueueCommandsAndMessagesResponse
makes the code long and tedious to readFinally for tradeoff in my own opinion, these additional code reuse with this is not as valuable as readability and extensibility.
SelectProcessExecutionForUpdate
/ UpdateProcessExecution
/SelectAsyncStateExecutionForUpdate
/ UpdateAsyncStateExecution
will limit how we can extend the waitUntil later (very soon, we will add timer command, and future GlobalQueue command). Or we will have to make this persistence API a giant combo for the new commands. SelectProcessExecutionForUpdate
/ UpdateProcessExecution
/SelectAsyncStateExecutionForUpdate
/ UpdateAsyncStateExecution
-- we may update more fields in WaitUntil processing, but just very few fields in processNewMessagesTask. We may want to use separate SQL API to improve the perf of write overhead (the JSON blob will have high overhead)
Why make this pull request?
Improve the logic of handling local queue messages and make exactly-once update to each table row.
What has changed
[Summarize what components of the repo is updated]
[Link to xdb-apis/xdb-golang-sdk PRs if it's on top of any API changes]
How to test this pull request?
[If writing Integration test in Golang SDK repo, please provide link to the pull request of Golang SDK Repo]
Checklist before merge
[ ] If applicable, merge the xdb-apis/xdb-golang-sdk PRs to main branch [ ] If applicable, merge the xdb-apis/xdb-apis PRs to main branch [ ] Update
go.mod
to use the commitID of the main branches for xdb-apis/xdb-golang-sdk