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
{{ message }}
Repository navigation
Query: Allow store types and type facets to be set explicitly (EF.StoreType) #4978
#4937 introduced logic to infer Unicode-ness for literals when comparing to column. It works well for simple cases when one side of comparison is ColumnExpression. Though there are complex cases in which we are not inferring the information correctly atm. For e.g.
If one side of binary expression is subquery selecting one element of a column then the other side should have same facets as the column being projected in subquery.
Operators like concat which return string type values should pass uniform information towards parent because the siblings of concat should have same unicode-ness as concat. (See test Non_unicode_string_literals_is_used_for_non_unicode_column_with_concat)
For cases like above, we can improve logic to propagate information. If it is too hard to do then we should add functions like AsUnicode & AsNonUnicode.
Also cases of SqlFunction like CharIndex (comes from String.Contains method) the argument should have same type mapping. Though That could be different for individual functions.
changed the title [-]Query: Infer unicode-ness for literals in complex cases[/-][+]Query: Allow type facets to be set explicitly and/or improve inference in complex cases[/+]on Jun 19, 2017
changed the title [-]Query: Allow type facets to be set explicitly and/or improve inference in complex cases[/-][+]Query: Allow store types and type facets to be set explicitly and/or improve inference in complex cases[/+]on May 7, 2018
changed the title [-]Query: Allow store types and type facets to be set explicitly and/or improve inference in complex cases[/-][+]Query: Allow store types and type facets to be set explicitly [/+]on Nov 13, 2019
Another possible need for this: setting facets in order to allow something to participate in a set operation (currently set operations over types with differing facets isn't supported, #19129).
changed the title [-]Query: Allow store types and type facets to be set explicitly [/-][+]Query: Allow store types and type facets to be set explicitly (EF.StoreType)[/+]on Sep 14, 2022
Note that this issue has been a bit ambiguous; we can use this issue to track explicitly forcing a type mapping on an arbitrary node, whereas #35045 is about adding an actual CAST() node into SQL.
Activity
smitpatel commentedon May 3, 2017
Also cases of SqlFunction like CharIndex (comes from String.Contains method) the argument should have same type mapping. Though That could be different for individual functions.
[-]Query: Infer unicode-ness for literals in complex cases[/-][+]Query: Allow type facets to be set explicitly and/or improve inference in complex cases[/+]ajcvickers commentedon Jun 19, 2017
Note: when designing/implementing this, consider the case for parameters passed to FromSql, etc. See #8895Added comment to that issue.
[-]Query: Allow type facets to be set explicitly and/or improve inference in complex cases[/-][+]Query: Allow store types and type facets to be set explicitly and/or improve inference in complex cases[/+]ajcvickers commentedon May 7, 2018
See also comments in #11921
ajcvickers commentedon Jun 29, 2018
See also comments in the thread here: #6717 (comment)
20 remaining items
[-]Query: Allow store types and type facets to be set explicitly and/or improve inference in complex cases[/-][+]Query: Allow store types and type facets to be set explicitly [/+]roji commentedon Dec 2, 2019
Another possible need for this: setting facets in order to allow something to participate in a set operation (currently set operations over types with differing facets isn't supported, #19129).
[-]Query: Allow store types and type facets to be set explicitly [/-][+]Query: Allow store types and type facets to be set explicitly (EF.StoreType)[/+]roji commentedon Nov 5, 2024
Note that this issue has been a bit ambiguous; we can use this issue to track explicitly forcing a type mapping on an arbitrary node, whereas #35045 is about adding an actual
CAST()node into SQL.