-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Refactor ConnectorMetadata to deprecate multi-layouts returning method #21933
Conversation
Hi @tdcmeehan, sorry for the misoperation that closed the last PR, so I open this new PR.
I'm a little not quite understand about your comment. Even if using |
@hantangwangd I see that the default method for |
@tdcmeehan Thanks for the explanation. Do you mean we should check that |
@hantangwangd my concern is someone implements both and due to a misunderstanding, they are not alerted that they have improperly coded their connector. To avoid this, I believe the engine itself should check that these two methods are equivalent, until |
Hi @tdcmeehan, as I understand, the main situation you concerned about is that someone who has correctly implemented the deprecated function If we make |
The engine should ensure that whatever is returned from both methods is identical. i.e.: ConnectorTableLayoutResult layoutForConstraintsResult = getTableLayoutForConstaint(...)
List<ConnectorTableLayoutResult> layoutsResult = getTableLayouts(...)
verify(layoutsResult.size() == 1)
checkState(layoutsResult.get(0).equals(layoutForConstraintsResult) |
OK, I understand, that makes sense. |
Hi @tdcmeehan, after check the code, I found it's a little complex to determine the equality of two In that case, if some one implements both the methods which return different objects that are semantically identical, they still may fail the check depending on specific connector implementation. So what's your opinion about this? Would it be better for the connectors to take on their own responsibility to make the correct SPI function implementation? |
@hantangwangd I hadn't considered that. I think given that constraint, what's written here is the best we can do. |
Description
The support for multiple layouts has been removed in PR #12674, however the SPI method
ConnectorMetadata.getTableLayouts()
still return aList<ConnectorTableLayoutResult>
which should always contains exactly one element. That's somehow unreasonable, and may lead in some confusion and inconvenience in the reading and subsequent development of the code. This PR try to deprecate this method, and replace it bygetTableLayoutForConstraint()
which explicitly return aConnectorTableLayoutResult
.Test Plan
Contributor checklist
Release Notes