Skip to content

Query: Allow store types and type facets to be set explicitly (EF.StoreType) #4978

Description

@smitpatel

#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.

  1. 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.
  2. 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.

Activity

  1. added this to the Backlog milestone on Apr 6, 2016
  2. smitpatel commented on May 3, 2017

    @smitpatel
    ContributorAuthor

    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.

  3. 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
  4. ajcvickers commented on Jun 19, 2017

    @ajcvickers
    Contributor

    Note: when designing/implementing this, consider the case for parameters passed to FromSql, etc. See #8895
    Added comment to that issue.

  5. 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
  6. ajcvickers commented on May 7, 2018

    @ajcvickers
    Contributor

    See also comments in #11921

  7. ajcvickers commented on Jun 29, 2018

    @ajcvickers
    Contributor

    See also comments in the thread here: #6717 (comment)

  8. modified the milestones: Backlog, on Jun 29, 2018
  9. 20 remaining items

  10. removed this from the Backlog milestone on Jun 6, 2019
  11. added this to the Backlog milestone on Jun 6, 2019
  12. removed their assignment
    on Jun 6, 2019
  13. 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
  14. roji commented on Dec 2, 2019

    @roji
    Member

    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).

  15. 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
  16. roji commented on Nov 5, 2024

    @roji
    Member

    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.

  17. added theissue type on Jun 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions