Closed wbuck closed 1 year ago
OK, It looks like the generated Expression
differences between what OData
does with ApplyTo
and what this library does, does not matter. The providers correctly convert the enum
to an integer.
So I think the real bug here is with the in
operator throwing an exception when you're filtering a root element.
Consider closing this one and posting a new issue regarding the in
operator problem?
Yeah I think that's the way to go.
Source/destination types
Mapping configuration
Version: x.y.z
Seen in master, as well as latest release.
Expected behavior
Consistent behavior when filtering by an
enum
property on root vs filtering an by anenum
property in a subquery.Actual behavior
When filtering by an
enum
property on root, the property is converted to anInt32
and compared to a constant integer value. When filtering by anenum
property in a subquery theenum
values are compared as-is, no conversion to the underlying type.Steps to reproduce
Above produces the following
Expression
's:When filtering by an
enum
property in a subquery no results will be returned (even when there are results to return).Currently to get around this issue I'm using the following
Operator
in theFilterHelper
in a few locations (I also had to handle the collection that's created for thein
operator but I talk about thein
operator below):NOTE there is also an issue with the
in
operator.Using the
in
operator when filtering by anenum
property on rootthrows
anSystem.InvalidOperationException
:This was produced with the following query:
"/CategoryModel?$filter=EnumProp in ('First', 'Second')"
This is the generated lambda expression when using the
in
operator on anenum
property in a sub query:This was produced with the following query:
"/CategoryModel?$expand=EnumerableProducts($filter=Ranking in ('First', 'Second'))"
I would have expected the prior lambda expression to instead look like the following for both filtering on root and in a subquery: