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
Improvement on #22049. Currently, when we don't have access to "natural" identifiers, (so we can't inject orderby to properly bucket the results in case of correlated subquery - this can happen for GroupBy and Distinct) we try to use what we have - entire projection in case of distinct and grouping key in case of GroupBy. Those still guarantee the uniqueness of the row, so it's ok to use them. However, current limitation is that we only do this if the entire projection is made of columns - we don't do it for anything more complex, say x.Name.Length. It should be perfectly fine to use more complex projection as it still guarantees the uniqueness of the row. The reason why we have the limitation is that we didn't have an easy way to get the proper comparer for this complex expression (in case of columns we use the comparer from type mapping).
Example of the query that could work: Correlated_collection_with_distinct_not_projecting_identifier_column_also_projecting_complex_expressions
ss.Set<Gear>().Select(
g =>new{Key=g.Nickname,Subquery=g.Weapons.Select(w =>new{w.Name,w.IsAutomatic,w.OwnerFullName.Length}).Distinct().ToList()}
The text was updated successfully, but these errors were encountered:
Improvement on #22049. Currently, when we don't have access to "natural" identifiers, (so we can't inject orderby to properly bucket the results in case of correlated subquery - this can happen for GroupBy and Distinct) we try to use what we have - entire projection in case of distinct and grouping key in case of GroupBy. Those still guarantee the uniqueness of the row, so it's ok to use them. However, current limitation is that we only do this if the entire projection is made of columns - we don't do it for anything more complex, say x.Name.Length. It should be perfectly fine to use more complex projection as it still guarantees the uniqueness of the row. The reason why we have the limitation is that we didn't have an easy way to get the proper comparer for this complex expression (in case of columns we use the comparer from type mapping).
Example of the query that could work: Correlated_collection_with_distinct_not_projecting_identifier_column_also_projecting_complex_expressions
The text was updated successfully, but these errors were encountered: