Skip to content
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

Extract type mapping postprocessing to an external visitor #33308

Merged
merged 2 commits into from
Mar 14, 2024

Conversation

roji
Copy link
Member

@roji roji commented Mar 13, 2024

Part of API review (#33220)

This extracts RelationalInferredTypeMappingApplier out of the translation visitor and makes it its own, independent postprocessing visitor. Note that I ended up not introducing a parameter object, but just passing in the general postprocessing dependencies that RelationalQueryTranslationPostprocessor has.

@roji roji requested a review from a team March 13, 2024 11:49
@roji roji mentioned this pull request Mar 13, 2024
45 tasks
@roji roji force-pushed the RefactorTypeMappingProcessor branch from 3dcabef to 1251ad3 Compare March 13, 2024 12:03
@roji roji force-pushed the RefactorTypeMappingProcessor branch from 1251ad3 to d1428e1 Compare March 13, 2024 16:49

return query6;
return query7;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see a weakness in this naming scheme

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah.. The main goal here was to allow examining the different stages of postprocessing when debugging, i.e. not overwrite the same query variable with each successive pipeline step. Adding steps seems rare enough that it's OK - but I'm open to other ideas...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could name them according to the last step: baseProcessedQuery, typeMappedQuery, projectionAppliedQuery, etc.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or go the QBASIC route: query10, query20, query30 ...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm worried about scalability, with future visitors coming to visit we may need to go into the hundreds/thousands here.

@@ -1328,11 +1323,11 @@ protected override ShapedQueryExpression TranslateUnion(ShapedQueryExpression so
/// Inferred type mappings for queryable constants/parameters collected during translation. These will be applied to the appropriate
/// nodes in the tree.
/// </param>
[Obsolete("Override RelationalQueryTranslationPostprocessor.ProcessTypeMappings() instead.", error: true)]
protected virtual Expression ApplyInferredTypeMappings(
Expression expression,
IReadOnlyDictionary<(string, string), RelationalTypeMapping?> inferredTypeMappings)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'd need to revert this to IReadOnlyDictionary<(TableExpressionBase, string), RelationalTypeMapping?> for the obsolete attribute to make sense

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re-introducing TableExpressionBase seems like a bit much... Given that the visitor base class (RelationalInferredTypeMappingApplier) is also being obsoleted, I'll just update the message there and remove this altogether - it should be more than enough to point provider writers in the right direction.

switch (expression)
{
case JsonEachExpression jsonEachExpression
when TryGetInferredTypeMapping(jsonEachExpression.Alias, "value", out var typeMapping):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these literals be extracted?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, a cleanup around this is probably in order.

@roji roji merged commit 98eaa39 into dotnet:main Mar 14, 2024
7 checks passed
@roji roji deleted the RefactorTypeMappingProcessor branch March 14, 2024 08:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants