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

Query: Remove public setters from custom expression properties #19346

Merged
merged 1 commit into from
Jan 6, 2020

Conversation

smitpatel
Copy link
Member

Resolves #19192

Changes

  • Only server side query expression are in place updated using private setters, public methods
  • Moved to Update method pattern in certain cases
  • TableExpressionBase still has internal set which will be fixed in Query: Assign aliases to tables differently #17337
  • ShapedQueryExpression.VisitChildren throws now. Since ShapedQuery contains query expression (server side) and shaper expression (client side), it is unlikely that a visitor needs to visit both components. Hence we force visitor to decide which component to visit. This improves perf as we wouldn't go into client side shaper when updating something in sql tree

roji
roji previously requested changes Dec 18, 2019
@@ -47,12 +47,25 @@ protected override Expression VisitExtension(Expression extensionExpression)
{
Check.NotNull(extensionExpression, nameof(extensionExpression));

return extensionExpression switch
#pragma warning disable IDE0066 // Convert switch statement to expression
switch (extensionExpression)
Copy link
Member

Choose a reason for hiding this comment

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

This should stay a switch expression... all the expressions are completely simple.

Copy link
Member Author

Choose a reason for hiding this comment

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

First case is multi-line.

Copy link
Member

Choose a reason for hiding this comment

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

Didn't we have this discussion already (or similar)? We have multi-line in conditional cases as well, which are also expressions (even nested multi-line)...

Copy link
Member

Choose a reason for hiding this comment

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

Not to mention the ugliness of having to have a pragma around this...

Copy link
Member Author

Choose a reason for hiding this comment

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

It does not look simple to me. I am not changing it.

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 do not consider this to be simple. The design meeting discussion we had specified guidelines to consider simple to be returning a specific value or calling into one method call. Nesting/Chaining is not something I consider simple.

Copy link
Member Author

Choose a reason for hiding this comment

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

Also design meeting decision was not to use newer feature if something is not agreeable.

Copy link
Member

Choose a reason for hiding this comment

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

I think we should discuss again with the team.

Copy link
Member

Choose a reason for hiding this comment

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

Just extract the first case to a method, then it becomes simple enough

Copy link
Member

Choose a reason for hiding this comment

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

I don't think we came to a consensus on this.

src/EFCore/Query/ShapedQueryExpression.cs Outdated Show resolved Hide resolved
src/EFCore/Query/ShapedQueryExpression.cs Show resolved Hide resolved
@smitpatel smitpatel dismissed roji’s stale review December 18, 2019 16:41

Feedback addressed.

@smitpatel smitpatel requested a review from roji December 18, 2019 16:41
@smitpatel smitpatel changed the title Query: Remove public setters from customer expression properties Query: Remove public setters from custom expression properties Dec 21, 2019
Resolves #19192

Changes
- Only server side query expression are in place updated using private setters, public methods
- Moved to Update method pattern in certain cases
- TableExpressionBase still has internal set which will be fixed in #17337
- ShapedQueryExpression.VisitChildren throws now. Since ShapedQuery contains query expression (server side) and shaper expression (client side), it is unlikely that a visitor needs to visit both components. Hence we force visitor to decide which component to visit. This improves perf as we wouldn't go into client side shaper when updating something in sql tree
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.

Query: Remove ability to mutate custom expressions with properties
5 participants