openapi-generator
openapi-generator copied to clipboard
OpenAPITools
[dart-dio][client] Unusable Enums Produced
Description
When generating a dart-dio client, unusable Enums are created.
ImageResolutionEnum resolution = ImageResolutionEnum.number196
The only property of the enum is name which is just a string of the enum name. You'd expect that the value of ImageResolutionEnum.number196 to equal 196, but it instead equals the string 'number196'.
openapi-generator version
2.5.2 via npm install.
OpenAPI declaration file content or url
I can't really share the openapi spec, as it's for my employer and the API hasn't been made public yet.
Command line used for generation
openapi-generator-cli generate -g dart-dio -i $SPEC_FILE -c "conf/dart_client.yaml" -o $path --enable-post-process-file
Steps to reproduce
Generate a client against an OpenApi spec which contains an IntEnum.
Related issues/PRs
Several related, but not quite similar issues have occurred in the past, regarding issues with enums in the dart-dio client generation.
Suggest a fix/enhancement
Enums should return the expected value, not the name of the enum.
2.5.2 is very old, we are currently at 6.x.
If the issue persists with the latest versions, please provide a spec.
We've updated our CI/CD pipeline to utilize version 6.4.0 of OpenAPI Generator. Here is an excerpt from our OpenAPI Spec, which contains an enum (this occurs with both String and Int enums).
{
"title": "PowerPlantType",
"enum": [
"ICE",
"HEV",
"BEV"
],
"description": "An enumeration."
}
This causes the build to fail.
ImageResolutionEnum.number196 is just the variable name, the variable contains a @BuiltValueEnumConst(wireNumber: 196) annotation which is used for serialization. Same goes for your second example.
We have samples here which work (https://github.com/OpenAPITools/openapi-generator/blob/master/samples/openapi3/client/petstore/dart-dio/petstore_client_lib_fake/lib/src/model/enum_test.dart) - otherwise please provide a reproducible example.
I think his point is that there is no way to easily get the original value of the mappings
E.G
static const Map<Object, String> _fromWire = const <Object, String>{
'lakewood': 'lakewood',
'passaic': 'passaic',
'monsey': 'monsey',
'flatbush': 'flatbush',
'queens': 'queens',
'brooklyn': 'brooklyn',
'five_towns': 'fiveTowns', # How would I get the original "five_towns" string?
'kj': 'kj',
};
I think his point is that there is no way to easily get the original value of the mappings
E.G
static const Map<Object, String> _fromWire = const <Object, String>{ 'lakewood': 'lakewood', 'passaic': 'passaic', 'monsey': 'monsey', 'flatbush': 'flatbush', 'queens': 'queens', 'brooklyn': 'brooklyn', 'five_towns': 'fiveTowns', # How would I get the original "five_towns" string? 'kj': 'kj', };
Yes, this is what I'm getting at. The anticipated names/value aren't maintained. They're technically there, but not in the anticipated form factor. Which means the API contract isn't maintained, from the perspective of an end user.
(Sorry, I've been crazy busy.)
It's possible using this:
extension CommunityEnumExt on CommunityEnum {
String get value {
return (CommunityEnum.serializer as PrimitiveSerializer<CommunityEnum>)
.serialize(serializers, this) as String;
}
}