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
Our current SQL pregeneration mechanism (#29753) takes into account the nullability of reference type parameters; that is, if a reference type variable is captured by the query, and that variable is annotated as non-nullable, our SQL generation takes that into account, generating optimal SQL (and also reducing the number of required SQL permutations).
However, the funcletizer currently only does this for directly captured variables, and notfor larger expressions composed on top of a captured variable (e.g. Where(b => b.Name == foo + "Bla")). Doing this would require bubbling nullability information up the tree via State, and knowing to correctly know to combine operand nullabilities per expression type.
The text was updated successfully, but these errors were encountered:
Our current SQL pregeneration mechanism (#29753) takes into account the nullability of reference type parameters; that is, if a reference type variable is captured by the query, and that variable is annotated as non-nullable, our SQL generation takes that into account, generating optimal SQL (and also reducing the number of required SQL permutations).
However, the funcletizer currently only does this for directly captured variables, and notfor larger expressions composed on top of a captured variable (e.g.
Where(b => b.Name == foo + "Bla")
). Doing this would require bubbling nullability information up the tree via State, and knowing to correctly know to combine operand nullabilities per expression type.The text was updated successfully, but these errors were encountered: