OData / lab

This repository is for exploring new ideas and developing early prototypes of various OData stacks.
Other
48 stars 59 forks source link

Properly handle type definitions elements in schema #103

Open habbes opened 4 years ago

habbes commented 4 years ago

Fixes issue #81

The connected service could not generate code for the Outlook Beta API mentioned in the related issue due to 2 main issue:

Issue 1

The outlook beta API mentioned in the related issue contained the following type definition:

<TypeDefinition Name="DateTime" UnderlyingType="Edm.String" />

Apparently the code generator did not know how to handle such cases. It tried to generate its code as an IEdmEntityType, and that lead to null-reference exceptions. Similar issues occurred when translating function parameters that whose types are based on type definitions.

This PR solves this issue in two ways:

  1. Ignore type definitions when writing classes/enums for entities, complex types and enums
  2. When writing function parameters, use the underlying primitive type of the type definition as the parameter type. E.g: a function defined in the schema as:
    <Function Name="MyFunc" IsBound="true">
    <Parameter Name="StartDate" Type="MyNamespace.DateTime" />
    <ReturnType Type="Edm.Int32" Nullable="false" />
    </Function>

    will be defined in the generated C# code as:

    public int MyFunc(string StartDate)
    {
    //...
    }

    Note that using MyNamespace.DateTime as a type in the C# code would cause compile-time errors because there's no equivalent C# type generated for the type definition by the code generator.

Issue 2

For edm types like TimeOfDay which are defined in the OData Edm library, the connected service was generating code in the wrong namespace, i.e. generating Microsoft.OData.Edm.Library.TimeOfDay instead of Microsoft.OData.Edm.TimeOfDay. It was probably generating code for an older version of the lib. The code generator itself uses an older version of edm lib (6.x). We should probably update it to 7.6 soon.

PS:

I created this branch based on my other un-merged PR (pull #100) instead of the master branch because the master branch still does not have any tests suits. As soon as the other PR is merged, I'll remove the Draft status for this PR and mark it officially ready for review.