No worries :)
Well, enums to string could be done, but there are some issues;
First, if the enum is a non mapped enum, it will not exist in the Edm, correct? those enums are just translated to integral type values in the DbExpression model.
So they've lost semantics.
But that might not be an real issue since you'd probably want to ToString mapped enums, evaluated from properties.
Or one could just pass the LinqExpression also to the ToString translator and extract enum info that way.
The easiest and naive solution would be to create a "Case" expression for those, mapping each value to a name.
But given that an enum could have an unspecified number of entries in it, I guess that could become ineffective in extreme cases.
So I take it that it is not the route to go, unless one throw on too big enums, explaining that those can't be translated.
This is the only way that will keep everything intact, since if I concat multiple values and an enum, you probably expect the concatenated string length to be correct.
e.g.
Length = ("prefix" + SomeEnum.xyz).Length
The total overkill approach would be to not concatenate strings at all at DB level and instead select as many columns as there are values to be concatenated and perform the concatenation client side, that way, every value could be ToString'ed.
But that would have a huge impact on the SQL generation and I take there are other issues with this too.
Or maybe enums could be mapped to support tables also, that could be used to lookup the name from their value.
But that seems like a huge effort for such an unrequested feature.
(it would however give referential integrity to enum fields if done that way, and maybe keep some DBA happy :P)
So in short, I guess it is the naive "Case" solution or no solution at all.
Well, enums to string could be done, but there are some issues;
First, if the enum is a non mapped enum, it will not exist in the Edm, correct? those enums are just translated to integral type values in the DbExpression model.
So they've lost semantics.
But that might not be an real issue since you'd probably want to ToString mapped enums, evaluated from properties.
Or one could just pass the LinqExpression also to the ToString translator and extract enum info that way.
The easiest and naive solution would be to create a "Case" expression for those, mapping each value to a name.
But given that an enum could have an unspecified number of entries in it, I guess that could become ineffective in extreme cases.
So I take it that it is not the route to go, unless one throw on too big enums, explaining that those can't be translated.
This is the only way that will keep everything intact, since if I concat multiple values and an enum, you probably expect the concatenated string length to be correct.
e.g.
Length = ("prefix" + SomeEnum.xyz).Length
The total overkill approach would be to not concatenate strings at all at DB level and instead select as many columns as there are values to be concatenated and perform the concatenation client side, that way, every value could be ToString'ed.
But that would have a huge impact on the SQL generation and I take there are other issues with this too.
Or maybe enums could be mapped to support tables also, that could be used to lookup the name from their value.
But that seems like a huge effort for such an unrequested feature.
(it would however give referential integrity to enum fields if done that way, and maybe keep some DBA happy :P)
So in short, I guess it is the naive "Case" solution or no solution at all.