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.

Sign up for GitHub

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

Jump to bottom

[BUG] Model classes generation with oneOf and allOf #1709

Open
ravthiru opened this issue Dec 19, 2018 · 1 comment
Open

[BUG] Model classes generation with oneOf and allOf #1709

ravthiru opened this issue Dec 19, 2018 · 1 comment
Labels
Issue: Bug

Comments

@ravthiru
Copy link

ravthiru commented Dec 19, 2018 •
edited
Loading

petstore.yaml.txt

Description

Generated model classes does not have references when using oneOf and allOf

Contact1 and Contact2 are generated but , Pet class does not have reference for Contact1 and Contact2

openapi-generator version

openapi-generator-maven-plugin 3.3.4

OpenAPI declaration file content or url
 Pet:
      type: object
      allOf:
      - oneOf:
        - type: object
          properties:
            contact1:
              $ref: '#/components/schemas/contact1'
        - type: object
          properties:
            contact1:
              $ref: '#/components/schemas/contact2'
      - allOf:
        - type: object
          properties:
              id:
                type: integer
                format: int64
              name:
                type: string
              tag:
                type: string
    contact1:
        type: object
        properties:
          location:
            type: string
          city:
            type: string
    contact2:
        type: object
        properties:
          email:
            type: string
          mobile:
            type: string
Command line used for generation
Steps to reproduce
Related issues/PRs
Suggest a fix
@tomghyselinck
Copy link
Contributor

#1842 might be a solution for you.
See also #1657, #1662, #1663 and #1664

coderbydesign added a commit to coderbydesign/insights-rbac that referenced this issue Feb 20, 2020
@coderbydesign
Set default limit on /access/ to max limit when no pagination limit s…
2388937 
…upplied

In a recent (PR)[RedHatInsights#195] we removed the default limit
on the `/access/` endpoint, to ensure all records were returned in a single request
instead of using the default of 10.

This meant in order to be backwards compatible, we'd also need to continue supporting
pagination params. To do this, we updated the spec to include `oneOf` two possible
valid responses, one paginated and one unpaginated. The `data` would remain the
same, but the meta data for pagination would not be included unless a `limit`
param was supplied in the request.

The associated updates were made to the `openapi.json` spec, but due to an existing
bug/issue in the OpenAPI Generator project [1,2], this breaks some client generation
which is used by app teams and QE, even though it's valid per the spec.

In order to avoid having a separate endpoint explicitly for a paginated responses,
and to also avoid constructing false meta data for pagination, we've decided to
set the default limit on the `/access/` endpoint equal to the max limit number
when no `limit` is supplied, but continue to respect the `limit` pagination param
when it is supplied.

This will allow for client generation to continue to work, and will allow those
using pagination by default to still be supported. For those not using pagination,
the response `data` should again still be the same, and the default limit will not
be a barrier to hitting pagination, as it will be the same as our max results.

[1] OpenAPITools/openapi-generator#15
[2] OpenAPITools/openapi-generator#1709
@coderbydesign coderbydesign mentioned this issue Feb 20, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Issue: Bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ravthiru @tomghyselinck