[BUG][Go] Badly formated enum name

[Magicking]

Description

Shared type is incorrectly formated (snake_case instead of camel case) and results in a non-exported type where it's properly camel_cased in other part of the code

openapi-generator version

4.3.0-Snapshot (latest docker image)

OpenAPI declaration file content or url

Steps to reproduce

Run the command above

Output

package openapi

type d string

// List of d
const (
    A D = "A"
    B D = "B"
)

Expected output

package openapi

type D string

// List of d
const (
    A D = "A"
    B D = "B"
)

Suggestion

Most probably a type writing function is missing a casing, it ca be worked around by using camel case in the specification.

[onitake]

I'm also using the latest docker image, and don't see this bug:

components:
  schemas:
    Status:
      type: string
      enum:
      - init
      - queued
      - running
      - done
      - error
      description: The current application status
      example: running

produces:

package openapi
// Status The current application status
type Status string

// List of Status
const (
    INIT Status = "init"
    QUEUED Status = "queued"
    RUNNING Status = "running"
    DONE Status = "done"
    ERROR Status = "error"
)

While the naming concept of the enum keys is questionable (they should be namespaced and in camel case IMHO), the type identifier is how it should be. Can you post your API spec?

[Magicking]

I have something like this:

components:
  schemas:
    **status_indicator**: // snake_case
      type: string
      enum:
      - init
      - queued
      - running
      - done
      - error
      description: The current application status
      example: running

This indeed end-up with the problem I described above, also I noticed that at every other place in the code, the type is properly camelCased.

I guess the temporary fix is to CamelCase type even in the specification.

[usadamasa]

I am suffering from the same problem. I understand that as a workaround, changing the specification can solve the problem. However, there are doubts about the operation of openapi-generator. Even if the specifications are the same, whether the generator converts to PascalCase with go or go-server is different.

openapi: 3.0.2
info:
  title: sample
  version: 0.1.0
servers: []
paths: {}
components:
  schemas:
    status_name: // snake_case
      type: string
      enum:
      - init
      - queued
      - running
      - done
      - error
      description: The current application status
      example: running

openapi-generator generate -i openapi.yaml -g go -o go-client

/*
 * ..snip..
 */

package openapi
// StatusName The current application status
type StatusName string // PascalCase

// List of status_name
const (
    INIT StatusName = "init"
    QUEUED StatusName = "queued"
    RUNNING StatusName = "running"
    DONE StatusName = "done"
    ERROR StatusName = "error"
)

openapi-generator generate -i openapi.yaml -g go-server -o go-server

/*
 * ..snip..
 */

package openapi
// StatusName : The current application status
type status_name string // snake_case

// List of status_name
const (
    INIT StatusName = "init"
    QUEUED StatusName = "queued"
    RUNNING StatusName = "running"
    DONE StatusName = "done"
    ERROR StatusName = "error"
)

I expect the generated code of go-client to be output. Is there a reasonable reason for this difference?

[Magicking]

Nice finding, this more and more looks like a patch welcome problem :(

[onitake]

If I may, I propose the following change:

components:
  schemas:
    status:
      type: string
      enum:
      - running
      - error
    status_snake:
      type: string
      enum:
      - running
      - error
    statusCamel:
      type: string
      enum:
      - running
      - error

This should produce:

package openapi
type Status string

// List of Status
const (
    StatusRunning Status = "running"
    StatusError Status = "error"
)

type StatusSnake string

// List of StatusSnake
const (
    StatusSnakeRunning StatusSnake = "running"
    StatusSnakeError StatusSnake = "error"
)

type StatusCamel string

// List of StatusCamel
const (
    StatusCamelRunning StatusCamel = "running"
    StatusCamelError Status = "error"
)

Possible caveats:

• If there is a symbol "StatusInit" somewhere else in the spec, this will lead to a conflict - There isn't any good way to resolve this and we should probably leave it up to the user.

[usadamasa]

I found a direct cause in mustache file.

Current version:

type *{{{name}}}* {{^format}}{{dataType}}{{/format}}{{#format}}{{{format}}}{{/format}}

Should:

type *{{{classname}}}* {{^format}}{{dataType}}{{/format}}{{#format}}{{{format}}}{{/format}}

https://github.com/OpenAPITools/openapi-generator/blob/v4.3.0/modules/openapi-generator/src/main/resources/go-server/model.mustache#L8

However, I do not know how much correction range is required. This is because the difference from the reference file is large.

https://github.com/OpenAPITools/openapi-generator/blob/v4.3.0/modules/openapi-generator/src/main/resources/go/model.mustache#L16

Do you have any ideas?

[onitake]

I'm slightly confused here... What exactly is go-server?

The Go generator uses conventions that are valid for a language like Java that has actual enums. For Go, the generated code does not conform to Go standards and should be changed. I don't quite see why there are two different Mustache templates here and how they apply...

[onitake]

FYI: Just found out that https://github.com/OpenAPITools/openapi-generator/blob/master/docs/generators/go.md documents an option called enumClassPrefix, which will likely solve the prefix issue.

Use it like this:

openapi-generator-cli generate -i schema.yml -g go -o openapi -p enumClassPrefix=true

Sadly this doesn't solve the problem described by the OP, as the type name is not translated to UpperCamelCase automatically.