Filtering on Double with different culture
agriffard opened this issue · 9 comments
Version
2.10.0
Details
When I try to call ApplyFiltering()
passing a filter on a Property which is a Double (ex: MyDoubleProperty>0.5
), an exception 'Argument types do not match' occurs:
at System.Linq.Expressions.Expression.Constant(Object value, Type type)
at Gridify.Syntax.ExpressionToQueryConvertor.GenerateExpression(Expression body, ParameterExpression parameter, ValueExpressionSyntax valueExpression, SyntaxNode op, Boolean allowNullSearch, Func`2 convertor)
at Gridify.Syntax.ExpressionToQueryConvertor.ConvertBinaryExpressionSyntaxToQuery[T](BinaryExpressionSyntax binarySyntax, IGridifyMapper`1 mapper)
at Gridify.Syntax.ExpressionToQueryConvertor.GenerateQuery[T](ExpressionSyntax expression, IGridifyMapper`1 mapper, Boolean isParenthesisOpen)
at Gridify.GridifyExtensions.ApplyFiltering[T](IQueryable`1 query, String filter, IGridifyMapper`1 mapper)
Steps to reproduce
Call ApplyFiltering()
with a filter on a Property which is a Double and a value that has a decimal point.
Hi @agriffard,
maybe you're missing something, because I've tried this and it is working as expected 🤔
using System.Collections.Generic;
using System.Linq;
using Xunit;
namespace Gridify.Tests;
public class Issue120
{
[Fact]
public void ApplyFiltering_WhenPassedADoubleValue_ShouldWorkCorrectly()
{
var query = new List<Test>()
{
new() { PropertyDouble = 0.2 },
new() { PropertyDouble = 0.6 },
new() { PropertyDouble = 0 },
}.AsQueryable();
var result = query.ApplyFiltering("propertyDouble > 0.5").ToList();
Assert.Single(result);
}
private class Test
{
public double PropertyDouble { get; set; }
public string Other { get; set; }
}
}
So weird! What dotnet version are you using? and what operating system? Although OS looks irrelevant just to make sure.
Windows 11 22621.2283
VS 2022 Preview (but same error on VS 2022)
C:\Users\agrif>dotnet --info
SDK .NET :
Version: 8.0.100-rc.1.23455.8
Commit: e14caf947f
Environnement d'exécution :
OS Name: Windows
OS Version: 10.0.22621
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\8.0.100-rc.1.23455.8\
.NET workloads installed:
Il n'y a aucune charge de travail installée à afficher.
Host:
Version: 8.0.0-rc.1.23419.4
Architecture: x64
Commit: 92959931a3
RID: win-x64
.NET SDKs installed:
6.0.414 [C:\Program Files\dotnet\sdk]
7.0.401 [C:\Program Files\dotnet\sdk]
8.0.100-rc.1.23455.8 [C:\Program Files\dotnet\sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.0-rc.1.23421.29 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.0-rc.1.23419.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.0-rc.1.23420.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Yeah because ,
is a special character (AND), so you need to escape it. more info : https://alirezanet.github.io/Gridify/guide/filtering.html#escaping
e.g: MyProperty > 0\,5
However, I'm thinking should I ignore the culture while parsing the values or not, since probably other users have different cultural settings and might want to use it in Gridify.
For now, you have two ways to fix this issue, either you need to escape the ,
character in your queries or change it on the OS level.
I'll probably add a setting to give users control over this behavior in the next version.
Escaping works.
Thank you @alirezanet for your answers and this great library.
You're welcome, happy to help.
there is also a third workaround which is changing the CurrentCulture
in your application,
CultureInfo.CurrentCulture = CultureInfo.GetCultureInfo("en-EN");
I've tested it and it works.