Created by: mnahkies
PR checklist
-
Read the contribution guidelines. -
Ran the shell script under ./bin/
to update Petstore sample so that CIs can verify the change. (For instance, only need to run./bin/{LANG}-petstore.sh
,./bin/openapi3/{LANG}-petstore.sh
if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in.\bin\windows\
. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first. -
Filed the PR against the correct branch: master
,4.1.x
,5.0.x
. Default:master
. -
Copied the technical committee to review the pull request if your PR is targeting a particular programming language.
Description of the PR
Whilst the spec states that the 'allOf' relationship does not imply a hierarchy:
While composition offers model extensibility, it does not imply a hierarchy between the models. To support polymorphism, the OpenAPI Specification adds the discriminator field.
Unfortunately this does not make sense for many existing use cases, that were supported by older versions of the generator. Therefore, I've restored the older behavior, specifically in the case that only a single possible parent schema is present.
I think a more complete solution would generate interfaces for the composed schemas, and mark the generated class as implementing these.
@wing328 I guess you're probably the best person to review this, given that you overhauled the support for anyOf
, allOf
, oneOf
originally.
I'd be interested if you had an alternative suggestion for achieving this without requiring the parent schema to know the identity of all the extending schema's - in our real definition collection, we have a set of common models that many different entities extend from in other definition files, and we have also build some common library functions that we use on the generated sub classes that accept objects extending from the parent.
Admittedly, our method of using allOf to express this feels awkward. Ideally I'd like a way to generate a generic Page<T>
class that could then be used as Page<Cat>
, Page<Dog>
, etc but I'm not aware of anyway to do this with the openapi spec / code gen tooling.
Example YAML:
openapi: 3.0.0
info:
title: example
description: example
version: 0.0.0
paths:
/test:
get:
tags:
- Test
summary: test
description: test
operationId: getCats
responses:
'200':
description: successful
content:
application/json:
schema:
$ref: '#/components/schemas/PagedCats'
components:
schemas:
Page:
properties:
page:
type: integer
required:
- page
Cat:
properties:
id:
type: string
format: uuid
required:
- id
Dog:
properties:
id:
type: string
format: uuid
required:
- id
PagedCats:
allOf:
- $ref: '#/components/schemas/Page'
- properties:
items:
type: array
items:
$ref: '#/components/schemas/Cat'
required:
- items
PagedDogs:
allOf:
- $ref: '#/components/schemas/Page'
- properties:
items:
type: array
items:
$ref: '#/components/schemas/Dog'
required:
- items
fixes #2845 (closed), and fixes #3523 (closed)