I observed this weird issue today when generating java client using maven codegen plugin, that enum values like OFF and ON are somehow ignored. Lets say in my YAML definition, there is:
laziness:
description: Flag to denote whether laziness should be enabled or disabled.
type: string
enum: [ ON, OFF ]
In the above scenario, no enum type is generated, and the class member laziness have the type String.
But, If the definition was as follows:
laziness:
description: Flag to denote whether laziness should be enabled or disabled.
type: string
enum: [ ON, OFF, MEH ]
Codegen generates the enum with just one value - MEH, and the class member is assigned the enum type.
But if I put quotes around them, like:
laziness:
description: Flag to denote whether laziness should be enabled or disabled.
type: string
enum: [ "ON", "OFF", "MEH" ]
All values are included in the generated enum.
I use the latest version of swagger-codegen-maven-plugin, version 2.1.6
PS: It works perfectly when generating from editor.swagger.io
Well, here's an interesting bit of information about YAML - values such as yes, Yes,On,onand their respective negative forms are actually considered booleantrue/false` values. What? Yes.
So when translating
laziness:
description: Flag to denote whether laziness should be enabled or disabled.
type: string
enum: [ ON, OFF ]
to JSON, you'd actually get....
{
"laziness": {
"description": "Flag to denote whether laziness should be enabled or disabled.",
"type": "string",
"enum": [
true,
false
]
}
}
And those aren't really valid values for a string-typed property are they? So they inadvertently end up being ignored.
How to work around it? Just like you did - you have to wrap the values in quotes. This is not really a bug with the codegen, this is just how YAML works.
For reference - http://yaml.org/type/bool.html
Maybe there should be an error or at least a warning when you get enum values which don't match the type attribute (or other schema restrictions), instead of simply ignoring them?
@webron
to JSON, you'd actually get....
{
"laziness": {
"description": "Flag to denote whether laziness should be enabled or disabled.",
"type": "string",
"enum": [
true,
false
]
}
}
Not really, I tried generating the JSON from editor.swagger.io, which generated the enum values as
"laziness": {
"description": "Flag to denote whether laziness should be enabled or disabled.",
"type": "string",
"enum": [
"ON",
"OFF"
]
},
That's because there's a bug in the converter (and many converters). Regardless, if you expect it to work _everywhere_ you _have to_ quote the values. You shouldn't expect it to work everywhere because buggy converters exist.
@ePaul - not sure how much control we have over the parsing if that's controlled by third party libraries, though @wing328 would be better to comment on that :)
I agree that a warning message would be helpful. My take is that it's more like a feature request/confirmation for the YAML parsing library in io.swagger.util.Yaml (swagger-core).
We'll mark this as a feature request pending the community to look into more (to see if there're better approaches).
We got bit by this today. I'm shocked that YAML has English synonyms for boolean values, and not surprised parsers fail to see the names as strings. (If they stick with this approach, then I want to be able to use _nyet_.)
Maybe this is something that could go into one of the validators as a warning, since it will break other applications in addition to codegen, right?
Most helpful comment
Well, here's an interesting bit of information about YAML - values such as
yes, Yes,On,onand their respective negative forms are actually considered booleantrue/false` values. What? Yes.So when translating
to JSON, you'd actually get....
And those aren't really valid values for a string-typed property are they? So they inadvertently end up being ignored.
How to work around it? Just like you did - you have to wrap the values in quotes. This is not really a bug with the codegen, this is just how YAML works.
For reference - http://yaml.org/type/bool.html