EnableDerivedTypesReferencesForResponses and EnableDerivedTypesReferencesForRequestBody only provide one level of inheritance support

[garethj-msft]

We use multiple levels of inheritance in our model.

At this point, the generated anyOf() for responses or request bodies is missin gout all of our leaf types as they are not directly inherited from the type of a navigation property.

This doesn't work for us as the key types we can pass to an API are simply missing.

It appears that EdmModelHelper.GetDerivedTypesReferenceSchema needs to walk the full hierarchy rather than stopping at one level.

[baywet]

@garethj-msft
If I understand what you're saying correctly, this is what the conversion used to do for user

anyOf:
  - directoryObject
  - user

when it should have done

anyOf:
  - entity
  - directoryObject
  - user

Is that what you meant? if so I believe it's been fixed since you created the issue, can you confirm by looking at the graph description for example please?

[garethj-msft]

Mmmm, I hadn't thought of whether entity should be some sort of special case, but it was more that I wanted

• directoryObject
• abstractUser
• concreteUser

wherein the API was defined as taking directoryObject, but the thing which can actually be passed is concreteUser.

[baywet]

passing more specific types (derived) should be supported today as long as the client code generator reflects the inheritance hierarchy.
How does the code generator detect an inheritance situation? that's a big assumption they hae to make because of the way json schema works. In kiota we assume that if we have a type defined as one any of a reference + one inline definition, that's inheritance, otherwise that's type union.
We were discussion about that with @darrelmiller earlier today.

[garethj-msft]

That seems like a big assumption. Seems safer to tie it to generating an OAS extension that is explicit about the inheritance perhaps? x-ms-base-class etc.?

[baywet]

That's one option we thought of that has the merit of making the generation process more reliable and the trade-off of making it less versatile (most OpenAPI description outside of Microsoft Graph/OData conversion won't have the information).
The alternatives being changing JSON Schema to carry that kind of information (unlikely to be accepted) or OpenAPI (more likely), I think @darrelmiller was mentioning that might already exist in 3.1 but I can't recall the specifics.

[darrelmiller]

@irvinesunday Could you confirm if this issue is resolved?

[baywet]

And to clear confusion from my earlier comment, I should have put allOf, not anyOf

[irvinesunday]

I believe the change we need to enforce to have all the derived types for given type would be:

OpenAPI.NET.OData/src/Microsoft.OpenApi.OData.Reader/Common/EdmModelHelper.cs

Line 27 in 1d9b54b

IEnumerable<IEdmSchemaElement> derivedTypes = edmModel.FindDirectlyDerivedTypes(structuredType).OfType<IEdmSchemaElement>();

to...

IEnumerable<IEdmSchemaElement> derivedTypes = edmModel.FindAllDerivedTypes(structuredType).OfType<IEdmSchemaElement>();