Fix type casting exceptions in 'isof' and 'cast' calls.

[WanjohiSammy]

Issues

This pull request fixes #1744.

Description

When using unquoted type parameters in isof and cast, the operations perform as expected provided that the source type can be cast to the target type. Issues arise when casting is not possible, resulting in the following exception:

Encountered invalid type cast. '{source type}' is not assignable from '{target type}'.

Lets say you have the following data model:

namespace NS;

public class Product
{
    public int ProductID { get; set; }
    // Others properties
    public Address SupplierAddress { get; set; }
}

public class DerivedProduct : Product
{
   public string AnotherProperty { get; set; }
    // Others properties
}

public class Address
{
    // Others properties
    public string City { get; set; }
}

Executing the query isof(NS.DerivedCategory) will throw the exception:

"Encountered invalid type cast. 'NS.Category' is not assignable from 'NS.Product'."

This occurs because ODL checks if NS.Product is related to NS.Category using the CheckRelatedTo function and since the types are not related or one is not a derivative of the other, the exception is thrown.

Main changes

According to the spec_cast and spec_isof specifications, there is no indication that an exception should be thrown if casting fails. This pull request introduces the TryBindDottedIdentifierForIsOfOrCastFunctionCall method, which handles the binding of DottedIdentifierToken specifically for the isof and cast function calls without performing the CheckRelatedTo validation, thereby preventing exceptions when type casting is not possible.

Checklist (Uncheck if it is not completed)

• Test cases added
• Build and test with one-click build and test script passed

Additional work necessary

If documentation update is needed, please add "Docs Needed" label to the issue and provide details about the required document change in the issue.

[habbes]

It may be better to call functionCallToken.Arguments.Select(...).ToList() than new List(...). If Arguments has a known collection size, then using ToList() could use an optimized path that avoids resizing. See:
dotnet/runtime#107560

[habbes]

What is the expected behaviour of cast() when the types are incorrect? If it doesn't throw an exception, what will happen? How is this scenario expected to be handled? How will a library like AspNetCore know that the cast is not possible? And would this be a breaking change?

[WanjohiSammy]

This is what is happening currently with cast with quoted type parameter

• ODL will bind literal type parameter token to ConstantNode using BindLiteral(LiteralToken literalToken). The AspNetCore library will get the cast node and tries to create LINQ Expression using Expression BindCastSingleValue(SingleValueFunctionCallNode node, QueryBinderContext context). It knows how to handle ConstantNode

For cast with unquoted type parameter

• ODL will bind DottedIDentifierToken as SingleResourceCastNode using a method I have added with this PR. To support this in AspNetCore, I will update function Expression BindCastSingleValue(SingleValueFunctionCallNode node, QueryBinderContext context) to add a condition to cast QueryNode to SingleResourceCastNode like what was done with the PR: Adding a condition to cast QueryNode to SingleResourceCastNode for Unquoted Type Parameter AspNetCoreOData#1313

[habbes]

Thanks for this added context. Can you also shed light on the behaviour with respect to handling of types where a cast is not possible? Ideally, from the user's endpoint the behaviour should be the same regardless of whether they user quoted or non-quoted syntax, and regardless of our internal implementation details which you have highlighted.

So could you clarify how we handle both supported and invalid cast scenarios in both quoted and unquoted variants? In which cases are we throwing an exception? Is the exception thrown consistent? Is that the expected behaviour?

My expectation is that isof should not throw an exception when a cast is invalid, but rather evaluate to a boolean that will perform the correct filter. I think cast throwing an exception when a cast is invalid is reasonable. What is not clear to me is whether such an exception should be thrown in ODL or AspNetCore. For the case of cast I would be cautious about changing the existing behaviour to avoid introducing a breaking change.

[WanjohiSammy]

With the current behavior, ODL does not throw exception or to be more specific, it doesn't check if target type is related to source type. It only bind the quoted type parameters to constant node and return the entire token as FunctionCall token. The AspNetCoreOData, on the other end, will get the token and try to create LINQ expression. If expression is not possible, AspNetCoreOData returns null BindSingleResourceCastFunctionCall will return null expression.

Let's look at this query:

/products?$filter=cast('Microsoft.AspNetCore.OData.E2E.Tests.Cast.Category')/Name eq 'Cat

AspNetCore will try to relate Entity Product to Entity Category in BindSingleResourceCastFunctionCall and returns null expression if one is not assignable from the other.

And then CreatePropertyAccessExpression will throw an expression when trying to get the Property Name from a null expression.

An exception like below will be thrown:

{
    "error": {
        "code": "",
        "message": "Instance property 'Name' is not defined for type 'System.Object'"
    }
}

[habbes]

Is this behaviour consistent with how cast is handled when the type param is quoted?

[WanjohiSammy]

• For quoted type parameter, ODL bind the token to ConstantNode and AspNetCore is responsible to create LINQ expression using Expression BindCastSingleValue(SingleValueFunctionCallNode node, QueryBinderContext context). It knows how to handle ConstantNode.
• For unquoted type parameter, ODL bind the token to SingleResourceCastNode. When bumping the ODL version in AspNetCore, I will have to update the method Expression BindCastSingleValue(SingleValueFunctionCallNode node, QueryBinderContext context) to allow cast to SingleResourceCastNode as well.

[habbes]

Is this behaviour consistent with how isof is handled when the type param is quoted?

[WanjohiSammy]

Same applied to isof as discussed in #3117 (comment), however, the method in AspNetCore that is responsible to create LINQ is different. Here is the method Expression BindIsOf(SingleValueFunctionCallNode node, QueryBinderContext context). I will also update this method to allow cast to SingleResourceCastNode as it currently only support cast to ConstantNode