"The LINQ expression could not be translated": string[] {}.Contains error if use as LINQ predicate

[mariomenjr]

Hey there!

I've been giving such a heavy use to this useful and fantastic piece of software that I've been able to spot another issue.

Let me explain the scenario:

WHERE x IN ("M", "W")

As you can see in the image below, the expression cov('PlanGroup', ['W', 'M']) has been created to achieve a WHERE IN-like predicate.

Once built, I save the returned Expression in the filterExpression variable, as shown at line 55 in the image below.

That breakpoint doesn't tell us much about what's happening in the expression. That is why in the next image, I am showing the Debug View property in the Text Visualizer. It all looks in order.

However, once is executed in the LINQ Where method, an exception is raised:

Is there something I am missing, like configurations or similar? or is it just something out of the scope of the library? Let me know if more information is needed.

I am using Entity Framework Core and Pomelo to query a MySQL database:

Just to mention that when an expression is built with the comparison operator cov but with an int[] type value, everything works fine.

Trying to debug by myself

As I faced this issue, I tried to debug it myself to contribute to such a useful tool. However, this error message was preventing me from building the solution.

[alexmurari]

Hi, @mariomenjr!

I think i've found the issue, it's a EF Core limitation, if you look closely, you'll see that Exprelsior builds the Contains method call with a IEqualityComparer instance of type StringComparer with the OrdinalIgnoreCase strategy,

Apparently, EF Core doesn't support string comparisons with that StringComparer, see issue dotnet/efcore#1222.

One way to solve this is to remove the StringComparer strategy from the Contains method on Exprelsior, but this means that comparisons will not ignore character casing anymore (the default comprarer is Ordinal) and I must ponder the implications of that (I even feel it's a breaking change). Or wait for EF Core to support this, which doesn't seen to be happening. 😆

As for the debuging error, it's because the assemblies are strong-name signed with a password protected key, I will look for a solution for that. In the meantime, you can just modify the project settings to remove the strong-name requirement.