Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Properly handle type definitions elements in schema #103

Draft
wants to merge 24 commits into
base: master
Choose a base branch
from

Conversation

habbes
Copy link
Contributor

@habbes habbes commented Jan 28, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant