Query: Throw error for unhandled derived query root expression #26579
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
No testing since it needs test assembly with multiple providers. Let me know if we have such assembly. (or if someone else could manually verify the change works). |
This is what the cross-store functional tests are for. |
|
Will add test there. Thanks. |
Query root design Core exposes QueryRootExpression which is base class for any query root so we can access EntityType out of it. This is needed for nav expansion and any potential future use case. Since any derived query root would derive from it, core assembly translates it only when type is exact match to QueryRootExpression. Relational layer also processes QueryRootExpression when they are mapped to default SqlQuery, which also uses exact type match now. Apart from QueryRootExpression, no other kind of query root which can appear in different providers should be derivable (else they need to use exact type match too). This rule makes relational ones sealed class. In case any one needs to derive from it, they need to add additional processing anyway. Provider specific derived query roots can be non-sealed. If anyone is deriving from it then they should be using their derived provider which process those nodes too and if the derived provider wasn't used and shipped provider is used then it is an error from user perspective. If derived query root is used on other provider (targeting diff database) then it will fail since even the base shipped query root is unknown. Resolves #26502
|
Added test for cross provider methods (including AsSplitQuery/AsSingleQuery no-op in InMemory) |
smitpatel
commented
Nov 9, 2021
maumar
approved these changes
Nov 19, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Query root design
Core exposes QueryRootExpression which is base class for any query root so we can access EntityType out of it. This is needed for nav expansion and any potential future use case.
Since any derived query root would derive from it, core assembly translates it only when type is exact match to QueryRootExpression.
Relational layer also processes QueryRootExpression when they are mapped to default SqlQuery, which also uses exact type match now.
Apart from QueryRootExpression, no other kind of query root which can appear in different providers should be derivable (else they need to use exact type match too).
This rule makes relational ones sealed class. In case any one needs to derive from it, they need to add additional processing anyway.
Provider specific derived query roots can be non-sealed. If anyone is deriving from it then they should be using their derived provider which process those nodes too and if the derived provider wasn't used and shipped provider is used then it is an error from user perspective. If derived query root is used on other provider (targeting diff database) then it will fail since even the base shipped query root is unknown.
Resolves #26502