EnableDerivedTypesReferencesForResponses and EnableDerivedTypesReferencesForRequestBody only provide one level of inheritance support
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.
@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?
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.
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.
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.?
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.
@irvinesunday Could you confirm if this issue is resolved?
And to clear confusion from my earlier comment, I should have put allOf, not anyOf
I believe the change we need to enforce to have all the derived types for given type would be: https://github.com/microsoft/OpenAPI.NET.OData/blob/1d9b54bd9a2d212ed6b4f14a963457de51a5f89b/src/Microsoft.OpenApi.OData.Reader/Common/EdmModelHelper.cs#L27
to...
IEnumerable<IEdmSchemaElement> derivedTypes = edmModel.FindAllDerivedTypes(structuredType).OfType<IEdmSchemaElement>();