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
The issue is that parameter/constant primitive collections aren't initially typed (i.e. they need to be inferred based on e.g. comparison to a column). If an untyped primitive collection ColumnExpression is compared to a typed ColumnExpression, we apply the inferred type mapping back on the collection. However, if the same untyped ColumnExpression is also compared to something untyped (e.g. "foo"), our current behavior is to apply the default type mapping in SqlExpressionFactory; this means that when inferring the type of the primitive collection, we have two conflicting type mappings - the default one (inferred from d != null above), and the non-default one (inferred from the comparison to SomeColumnWithNonDefaultMapping).
The proper solution here would be to stop inferring the default type mapping in SqlExpressionFactory, and to leave the ColumnExpression null; that would allow us to apply the inferred type mapping on it later (based on SomeColumnWithNonDefaultMapping above). We would then need to also re-apply type mappings as the visit goes back up the tree, applying the inferred type mapping from d to "foo" in the above example.
The text was updated successfully, but these errors were encountered:
Example scenario which doesn't currently work - with a non-default type mapping
The issue is that parameter/constant primitive collections aren't initially typed (i.e. they need to be inferred based on e.g. comparison to a column). If an untyped primitive collection ColumnExpression is compared to a typed ColumnExpression, we apply the inferred type mapping back on the collection. However, if the same untyped ColumnExpression is also compared to something untyped (e.g. "foo"), our current behavior is to apply the default type mapping in SqlExpressionFactory; this means that when inferring the type of the primitive collection, we have two conflicting type mappings - the default one (inferred from
d != null
above), and the non-default one (inferred from the comparison to SomeColumnWithNonDefaultMapping).The proper solution here would be to stop inferring the default type mapping in SqlExpressionFactory, and to leave the ColumnExpression null; that would allow us to apply the inferred type mapping on it later (based on SomeColumnWithNonDefaultMapping above). We would then need to also re-apply type mappings as the visit goes back up the tree, applying the inferred type mapping from d to "foo" in the above example.
The text was updated successfully, but these errors were encountered: