You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a querystring is parsed that contains < > <= >= operators on two strings, the expression parser passes it through unchanged, which results in an error. Underneath, in SQL, strings can be compared ordinally with these operators, but EntityFramework requires them to be expressed as:
Unfortunately I cannot figure out how to use Configuration to replace GreaterThanNode et all with custom versions that can create these expressions. Am I correct in saying that CustomNodeMappings can't replace existing node types in this sort of way?
In any case, making it an extension isn't really important because converting these operators to CompareTo for strings is probably always going to be more useful than the error that we'd get otherwise, even if the underlying provider doesn't always have direct support for CompareTo like EF does.
The text was updated successfully, but these errors were encountered:
I've written a patch that creates a new OrdinalNode abstract class that has a BuildOrdinalExpression method that has the same signature of BuildQueryExpression except that it takes an ExpressionType as an additional parameter. It then checks to see if both operands are strings and if so, returns a CompareTo expression, otherwise it calls through to ApplyEnsuringNullablesHaveValues unchanged.
Would you use that?
If a querystring is parsed that contains < > <= >= operators on two strings, the expression parser passes it through unchanged, which results in an error. Underneath, in SQL, strings can be compared ordinally with these operators, but EntityFramework requires them to be expressed as:
Unfortunately I cannot figure out how to use Configuration to replace GreaterThanNode et all with custom versions that can create these expressions. Am I correct in saying that CustomNodeMappings can't replace existing node types in this sort of way?
In any case, making it an extension isn't really important because converting these operators to CompareTo for strings is probably always going to be more useful than the error that we'd get otherwise, even if the underlying provider doesn't always have direct support for CompareTo like EF does.
The text was updated successfully, but these errors were encountered: