[BUG] Inheritance is broken

[jonrimmer]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• What's the version of OpenAPI Generator used?
• Have you search for related issues/PRs?
• What's the actual output vs expected output?

Description

Basic inheritance, as described in the OpenAPI spec does not work.

Instead of creating a class / interface hierarchy using inheritance to represent the composition, all properties are flattened into the subclass.

openapi-generator version

4.0.0-20190508.072036-627 or master

OpenAPI declaration file content or url

schema.yaml:

openapi: "3.0.1"
info:
  version: 1.0.0
  title: Inheritance test
paths:
  /order:
    get:
      summary: Product order details
      operationId: getOrder
      responses:
        '500':
          description: Successful load
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ExtendedErrorModel'
components:
  schemas:
    BasicErrorModel:
      type: object
      required:
        - message
        - code
      properties:
        message:
          type: string
        code:
          type: integer
          minimum: 100
          maximum: 600
    ExtendedErrorModel:
      allOf:
        - $ref: '#/components/schemas/BasicErrorModel'
        - type: object
          required:
            - rootCause
          properties:
            rootCause:
              type: string

Expected output

The following class/interface hierarchy: to be generated:

• BasicErrorModel <- ExtendedErrorModel

Actual output

Three unrelated classes/interfaces:

• BasicErrorModel
• ExtendedErrorModel
• ExtendedErrorModelAllOf

Command line used for generation

java -jar openapi-generator-cli.jar generate -i ./schema.yaml -g typescript-angular -o src

I have also tried with the Java generator, and it creates the same hierarchy, so it is not just a Typescript problem.

Steps to reproduce

1. Copy the above yaml into schema.yaml locally.
2. Run the command above.
3. Examine the generated code.

Suggest a fix

I'm not familiar with the codebase, but it appears that getParentName in ModelUtils.java only considers a class as a viable parent for inheritance if it has a discriminator, but the above inheritance pattern does not use discriminators.

[auto-labeler]

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

[jonrimmer]

As mentioned, this is not just a TypeScript issue, as I can also reproduce it with the Java generator, so the above label is wrong.

[jonrimmer]

See also this inheritance example, again taken directly from the OpenAPI docs:

openapi: "3.0.1"
info:
  version: 1.0.0
  title: Inheritance test
paths:
  /pets:
    patch:
      requestBody:
        content:
          application/json:
            schema:
              oneOf:
                - $ref: '#/components/schemas/Cat'
                - $ref: '#/components/schemas/Dog'
              discriminator:
                propertyName: pet_type
      responses:
        '200':
          description: Updated
components:
  schemas:
    Pet:
      type: object
      required:
        - pet_type
      properties:
        pet_type:
          type: string
      discriminator:
        propertyName: pet_type
    Dog:     # "Dog" is a value for the pet_type property (the discriminator value)
      allOf: # Combines the main `Pet` schema with `Dog`-specific properties 
        - $ref: '#/components/schemas/Pet'
        - type: object
          # all other properties specific to a `Dog`
          properties:
            bark:
              type: boolean
            breed:
              type: string
              enum: [Dingo, Husky, Retriever, Shepherd]
    Cat:     # "Cat" is a value for the pet_type property (the discriminator value)
      allOf: # Combines the main `Pet` schema with `Cat`-specific properties 
        - $ref: '#/components/schemas/Pet'
        - type: object
          # all other properties specific to a `Cat`
          properties:
            hunts:
              type: boolean
            age:
              type: integer

The code generated for this spec is broken and unusable.

[jonrimmer]

I am seeing the same issues for the test files in the project. These generate broken code:

• allOf.yaml
• allOfDuplicatedProperties.yaml
• allOfMappingDuplicatedProperties.yaml

Etc.

How on Earth is the project passing all its tests when the output is this state?

EDIT: I see now that the petstore.yaml that is being used to regression test every generator doesn't contain any use of anyOf, allOf, oneOf, discriminators, etc. There's no way you can catch issues with these features, even when they're massively broken, like now.

[macjohnny]

@jonrimmer you are right, there should be some more tests. would you like to give a hand?
cc @wing328

[macjohnny]

you could e.g. add an integration-test similar to https://github.com/OpenAPITools/openapi-generator/blob/master/samples/client/petstore/typescript-angular-v6-provided-in-root/pom.xml with a separate yaml-file.

[lacksfish]

Could this be a related issue? #2580

[wing328]

We just started adding better support for allOf, anyOf, oneOf to different generators and I foresee it will take a while for all generators to support these new features in OAS v3.

If you or anyone wants to help with the implementation of these new features in any generators, let me know and I'll show you some good starting points.

[lacksfish]

There's already issues referencing multiple path parameters as $ref at the same time to have them merged. allOf, anyOf and oneOf would be nice to have, but the generators get confused with way less complex input already.

Personally, I'm simply looking for the functionality that complies with the OAS spec and outputs the generated code. I'm patient, and in the meantime I will simply try to discard/replace parts of my yaml spec that are not supported or broken by openapi-generator.

Thank you for making this public library and tooling resource and I'm looking forward to the first upcoming 4.0 point release.

[jonrimmer]

@wing328 This is not about enhancing generators, it's an issue of fixing DefaultCodegen.java to create the models correctly in the first place. The changes made to support multiple inheritance and OA3 appear to have made the situation worse, not better. For example, basic Swagger 2.0 allOf aggregation works in the current release version, but is broken in the snapshot, because the code for resolving parents now only understands discriminator-based parent relationships. If 4.0 is released as-is, it is going to break with a lot of specs that previously worked.

There should have been a comprehensive regression test for what aggregation was supported before the attempts to implement OA3 began, to ensure those changes didn't break anything. As things stand, the codebase is already broken WRT inheritance, so the task now is to both implement a comprehensive regression test while simultaneously fixing the default codegen. I'm happy to try to help with this, but it's going to take me a while to understand everything that's happening in DefaultCodegen.java.

[wing328]

I'll retest tomorrow and next week to repeat the problem you reported about allOf

[wing328]

Expected output
The following class/interface hierarchy: to be generated:

BasicErrorModel <- ExtendedErrorModel

@jonrimmer I read your issue report again and notice there may be an incorrect interpretation of allOf (composition vs inheritance).

In the example you provided, BasicErrorModel does not contain discriminator (example) so model composition is used instead

Ref:

• https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md#discriminator-object
• https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md#schemaComposition

[jonrimmer]

@wing328 The discriminator is intended to tell API consumers how they can polymorphically distinguish the type of an incoming object, it doesn't imply that a code generator must flatten any relationship without a discriminator in order to represent the composition.

At the very least, this decision should be left up to the language-specific generator rather than being made prematurely in the default codegen. TypeScript for example has absolutely no problem representing this kind of discriminator-less composition via interfaces, which do not imply any kind of runtime inheritance hierarchy, but allow for types to represent an extension/composition of one or more parent types.

And, indeed, this is exactly how the current release of openapi-generator works!

Run the example I provided through the release available in homebrew, and you will get an interface ExtendedErrorModel that inherits from an interface BasicErrorModel, exactly as you would expect. It is only with the current snapshot that you get these three, unrelated interfaces:

BasicErrorModel
ExtendedErrorModel
ExtendedErrorModelAllOf

This is just not right, and is happening because DefaultCodegen is prematurely deciding to throw away the child-parent relationship expressed by the allOf, perhaps based on the incorrect assumption that Java-style class hierarchies are the only type of extension mechanism in existence?