The current support for string concatenation is quite limited.
So I've been playing around with it in my fork for issue1904.
The current behavior for string concat is based on two different ways.
First a CallTranslator for String.Concat, and also AddTranslator if both left and right args are strings.
In my fork, I rewrote this to use the same underlying code.
So ConcatTranslator passes all its arg to a shared concat function.
The same goes for AddTranslator, I check if the node is a string concat node by testing if the BinaryExpression.Method is String.Concat*
If it is a string concat node, I flatten the left and right args recursively so that I get a list of concatenated args, and pass those to the same shared concat function as ConcatTranslator does.
Does this seem like a reasonable approach?
It allows me to apply the same behavior and optimizations for both ways of string concat.
It also comes with the benefit that I can pre-filter any constant null expression before translation.
Thus, eliminating the problem with trying to translate untyped constant nulls from add nodes
I also made it possible to concat strings with other primitives, e.g. int, int? , Guid, bool etc.
And since I had this support in place, I also added .ToString() support to those.
Maybe I got a bit carried away here, I made some custom transforms to those primitives.
Booleans are translated to True/False instead of 1/0.
Guids are translated to lowercase strings since that is how .NET guids look.
I figured that it would be best to keep the consistency with .NET as much as possible w/o generating too weird SQL.
Does this seem reasonable?
So I've been playing around with it in my fork for issue1904.
The current behavior for string concat is based on two different ways.
First a CallTranslator for String.Concat, and also AddTranslator if both left and right args are strings.
In my fork, I rewrote this to use the same underlying code.
So ConcatTranslator passes all its arg to a shared concat function.
The same goes for AddTranslator, I check if the node is a string concat node by testing if the BinaryExpression.Method is String.Concat*
If it is a string concat node, I flatten the left and right args recursively so that I get a list of concatenated args, and pass those to the same shared concat function as ConcatTranslator does.
Does this seem like a reasonable approach?
It allows me to apply the same behavior and optimizations for both ways of string concat.
It also comes with the benefit that I can pre-filter any constant null expression before translation.
Thus, eliminating the problem with trying to translate untyped constant nulls from add nodes
I also made it possible to concat strings with other primitives, e.g. int, int? , Guid, bool etc.
And since I had this support in place, I also added .ToString() support to those.
Maybe I got a bit carried away here, I made some custom transforms to those primitives.
Booleans are translated to True/False instead of 1/0.
Guids are translated to lowercase strings since that is how .NET guids look.
I figured that it would be best to keep the consistency with .NET as much as possible w/o generating too weird SQL.
Does this seem reasonable?