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: Refactor SearchConditionTranslatingVisitor #7554

Merged
merged 1 commit into from
Feb 7, 2017

Conversation

smitpatel
Copy link
Contributor

@smitpatel smitpatel commented Feb 4, 2017

Resolves issue #7271
part of #7520

}

protected override Expression VisitBinary(BinaryExpression expression)
{
Expression newLeft;
Expression newRight;
// Visit the children
Copy link
Contributor

Choose a reason for hiding this comment

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

remove this comment - seems inaccurate (visit children comes later)


newLeft = AdjustExpressionType(Visit(expression.Left), expression.Left.Type);
newRight = AdjustExpressionType(Visit(expression.Right), expression.Right.Type);
// Update the node
Copy link
Contributor

Choose a reason for hiding this comment

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

remove this comment as seems redundant - fairly obvious what the code is doing here


return expression.Update(newLeft, expression.Conversion, newRight);
// Do conversion
return _isSearchCondition
Copy link
Contributor

Choose a reason for hiding this comment

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

This pattern in repeated several times, consider DRYing it up.

protected override Expression VisitConditional(ConditionalExpression expression)
{
// Visit the children
Copy link
Contributor

@maumar maumar Feb 4, 2017

Choose a reason for hiding this comment

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

remove comment

var ifTrue = Visit(expression.IfTrue);
var ifFalse = Visit(expression.IfFalse);

_isSearchCondition = parentIsSearchCondition;

var newExpression = Expression.Condition(test, ifTrue, ifFalse);
// Update the node
Copy link
Contributor

@maumar maumar Feb 4, 2017

Choose a reason for hiding this comment

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

remove comment

}

if (expression.NodeType == ExpressionType.Not)
// Visit the children
Copy link
Contributor

Choose a reason for hiding this comment

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

remove comment

expression.Operand,
Expression.Constant(false, expression.Operand.Type));
}
// Update the node
Copy link
Contributor

Choose a reason for hiding this comment

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

remove comment

if (_isSearchCondition)
{
var parentIsSearchCondition = _isSearchCondition;
// Visit the children
Copy link
Contributor

Choose a reason for hiding this comment

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

remove comment

}

protected override Expression VisitParameter(ParameterExpression expression)
private static Expression MakeCompareToExpression(Expression expression, bool compareTo)
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: maybe 'Build' or 'Create' instead of 'Make'

@anpete
Copy link
Contributor

anpete commented Feb 4, 2017

Does it make sense to move from "SearchCondition" to "Predicate" for consistency?


return Expression.Equal(newExpression, Expression.Constant(true, typeof(bool)));
}
newExpression = new SearchConditionTranslatingVisitor(searchCondition).Convert(newExpression);
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we call Visit instead on Convert?

Copy link
Contributor

Choose a reason for hiding this comment

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

I find the naming confusing. Is it that this visitor is a predicate translator that performs a different translation when the target expression is a search condition?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I also need suggestions for name. Visit would be starting method for every expression. But the code block should be applied only at top level or starting expression. I moved the extra handling at top level inside the visitor to make it more contained in itself.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

How about Translate as method name?

This is visitor which converts value to search condition or vice-versa as needed. It is applied to predicates/join conditions & projections. After thinking more about name of the visitor,
I believe it shouldn't be named with Predicate.

Copy link
Contributor

Choose a reason for hiding this comment

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

Translate is fine. I was looking for symmetry with the 3 lines above, but I see why it needs a custom entry point method.

How about something like:

new BooleanExpressionTranslatingVisitor().Translate(expression, searchCondition: false);

@@ -1623,245 +1607,219 @@ var constantExpression

private class SearchConditionTranslatingVisitor : RelinqExpressionVisitor
{
/*
Copy link
Contributor

Choose a reason for hiding this comment

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

Put this in /// Summary doc comment

@smitpatel
Copy link
Contributor Author

It was named "SearchCondition" because T-Sql uses that term. I am fine with using "Predicate" or anything else also.

@smitpatel smitpatel force-pushed the searchConditionRefactor branch from f89471d to f8a2918 Compare February 4, 2017 05:55

return Expression.Equal(newExpression, Expression.Constant(true, typeof(bool)));
}
newExpression = new SearchConditionTranslatingVisitor(searchCondition).Convert(newExpression);
Copy link
Contributor

Choose a reason for hiding this comment

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

Translate is fine. I was looking for symmetry with the 3 lines above, but I see why it needs a custom entry point method.

How about something like:

new BooleanExpressionTranslatingVisitor().Translate(expression, searchCondition: false);

@smitpatel smitpatel force-pushed the searchConditionRefactor branch 2 times, most recently from b2ab380 to 98a8049 Compare February 7, 2017 20:39
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.

4 participants