Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[#6042] refactor: Delete the privilege of catalog after dropping the catalogs #6045
base: main
Are you sure you want to change the base?
[#6042] refactor: Delete the privilege of catalog after dropping the catalogs #6045
Changes from 2 commits
6f7968b
24aec9f
2eaa909
eb5b9cc
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There seems no need to extract this logic as a method.
Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer putting the logic into
AuthorizationUtils
.callAuthorizationPluginImpl
is a private implement method.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Em... then why don't we publicize this
callAuthorizationPluginImpl
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer putting similar logic to one place. Other similar logic are in the class AuthorizationUtils, It's better to maintain the code.
I don't preferring expose more implement methods to other package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we return
true
directly here?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If not exist, we should return false directly. Changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Emm ... think twice about the protocol please.
This function returns a boolean. You can use it for one of two purposes:
dropCatalog
operation was successful;Both are okay.
I'm more inclined to the second pattern and the reason is that I would expect
each function to serve a business logic with a business purpose.
This is a hint I got from line 141, where the function returns
dropped
as a boolean.To be consistent, I'd see a negative return value as catalog not dropped.
This is not a mandatory change request. I was just dumping my brain on the
(functional) interface design. It is still okay to return
false
in this case,which means the return value is about whether the operation was successful or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the catalog doesn't exist, we would return false. Our other code follows this rule, too. Only the catalog exists, we would return true. If we occurs some errors, we would throw exceptions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. I wasn't suggesting that this is a right or wrong issue.
It is in a gray area, which means we have to cope with it carefully.
We'd better have a clear mindset / protocol on this.
This, again, leads us to the situation of multiple exit conditions. We may return
true
/false
AND we may throw exceptions. That is not a good design for primitive functions. There are two options that are simpler and clearer:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your suggestion. I got your concern. It's a bigger topic. For this pull request, I will the semantic as community discussed before. You can discuss this topic in #5031 if you have concern.