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
In some rare cases, during query translation we want to change the CLR type, but without an actual SQL conversion being necessary. For example, if an enum that's value-converted to string has ToString() called on it, nothing needs to be done in SQL (the database value is already a string), but in the query tree we need to switch from the enum type to string.
Ideally we'd be able to simply replace the enum-typed node with an identical string-typed node - but there's no reliable way to change all node types (column, function call...), unless we introduce e.g. an abstract WithType() to SqlExpression.
The alternative way would be to add a special conversion node - which would extend SqlExpression - but to simply skip it in SQL generation. The disadvantage here is that any sort of pattern matching on the node would fail (e.g. is this node a column?).
In the meantime, we'd applying a SQL conversion, which should be a no-op.
The text was updated successfully, but these errors were encountered:
In some rare cases, during query translation we want to change the CLR type, but without an actual SQL conversion being necessary. For example, if an enum that's value-converted to string has ToString() called on it, nothing needs to be done in SQL (the database value is already a string), but in the query tree we need to switch from the enum type to string.
Ideally we'd be able to simply replace the enum-typed node with an identical string-typed node - but there's no reliable way to change all node types (column, function call...), unless we introduce e.g. an abstract WithType() to SqlExpression.
The alternative way would be to add a special conversion node - which would extend SqlExpression - but to simply skip it in SQL generation. The disadvantage here is that any sort of pattern matching on the node would fail (e.g. is this node a column?).
In the meantime, we'd applying a SQL conversion, which should be a no-op.
The text was updated successfully, but these errors were encountered: