Openapi-generator: [BUG] allOf to generate a model

[jaumard]

I'm using this definition to simulate genericity of paging result:

responses:
        200:
          description: 'List of products for the shop'
          content:
            application/json:
              schema:
                title: ‘ProductList',
                allOf:
                  - $ref: '#/components/schemas/PaginateResults'
                  - type: object
                    properties:
                      results: 
                        type: array
                        items: 
                          $ref: '#/components/schemas/Product'

I'm expecting this to generate a ProductList model that contains PaginateResults and the additional one. Problem is that it doesn't generate ProductList at all only PaginateResults and Product. And the generated method return only a PaginateResults which is incorrect.

I checked under DefaultCodegen::getSchemaType and it return only the first allOf it found, I manage to check and return the title if it's set, but that's solve only half the problem as ProductList is still not generated :/ only the method definition is correct now

Any idea ?

[wing328]

As discussed over IM, before we improve the inline model resolver to works better with inline allOf, a workaround is to define the model with allOf separately and use $ref instead.

[jaumard]

Thanks for the workaround !

[dskvr]

Hey @wing328, this workaround doesn't seem to work. Please see #2108

[bligny]

I have the exact same requirements as @jaumard : modeling browsable lists being the aggregation (allof) of paging info and an array of list items.

I confirm that (with version 3.3.4, not tested yet with v4) the inline version is not working, while the suggested workaround does the trick.

I personally dislike the workaround: in my 'definitions' sections, I only want to see my domain entities (like Product), I do not want to pollute it with 'container' structures (like ProductList)
IMHO the best place to put list-oriented structures is "_responses_" not "_definitions_".
Therefore, I find the inline solution is much more elegant.

@wing328
Do you intend to fix this bug soon ?