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.

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

[Java] Bug - Doesn't generate correct classes for models with same nested properties #8948

Open
bcampolo opened this issue Mar 10, 2021 · 4 comments

Comments

@bcampolo
Copy link

bcampolo commented Mar 10, 2021

Description

When an inline model has two or more properties that are inline objects (not using $ref) and those objects have the same set of properties the generator combines them in to a single Java class and references that class for both children properties even though these objects may not be conceptually related at all (see YAML example below)

openapi-generator version

5.0.1

OpenAPI declaration file content or url
components:
  schemas:
    Receipt:
      type: object
      properties:
        Order:
          type: object
          properties:
            id:
              type: integer
              format: int64
            name:
              type: string
        Customer:
          type: object
          properties:
            id:
              type: integer
              format: int64
            name:
              type: string
Command line used for generation

generate -i -g java --additional-properties=withXml=false,java8=true,library=native,serializationLibrary=jackson,dateLibrary=java8,hideGenerationTimestamp=true -o ./client

Steps to reproduce

Run generator using the above command line on a YAML file that includes the above snippet and you will get code that looks like this for Receipt:

public class Receipt {
  @SerializedName("Order")
  private ReceiptOrder order = null;

  @SerializedName("Customer")
  private ReceiptOrder customer = null;

Note both the "order" property and the "customer" property are of type ReceiptOrder which while functional seems wrong or at the very least confusing to anyone using the client, especially for methods with signatures like: setCustomer(ReceiptOrder customer)

Related issues/PRs

Not for openapi-generator but in swagger-codegen:
swagger-api/swagger-codegen#4883

Suggest a fix/enhancement

I would assume the default would not combine objects and would only combine objects when a $ref was used explicitly. At the very least an option should be provided to turn this combining logic off.

@auto-labeler
Copy link

auto-labeler bot commented Mar 10, 2021

👍 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.

@wing328
Copy link
Member

wing328 commented Mar 15, 2021

As a workaround, add the title attribute to the inline schema or define these models separately and use $ref instead.

@wrightsonm
Copy link

@wing328 where should the title attribute be placed?
I am seeing the same issue (but title has already been specified)

"400": {
  "description": "Invalid request.",
  "schema": {
                            "title": "unqiueNamePost400Response",
                            "type": "object",
                            "properties": {
                                "submitTimeUtc": {

@rudrakshtripathi
Copy link

$ref for Separate Definitions
To prevent the generator from merging the two inline objects, you can define separate schemas for Order and Customer, and then use $ref to reference those schemas in your Receipt object.

Here's how you can modify your OpenAPI YAML -
components: schemas: Order: type: object properties: id: type: integer format: int64 name: type: string Customer: type: object properties: id: type: integer format: int64 name: type: string Receipt: type: object properties: Order: $ref: '#/components/schemas/Order' Customer: $ref: '#/components/schemas/Customer'
In this case, separate Java classes Order and Customer will be generated, and you won’t face the merging issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants