You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are some cases, when you want to generate enums as simple constants, to get move flexibility on future releases.
Let assume response body contains list of next object:
Field {
FieldType type;
String value;
}
Your customer takes current version of client, parses that list, extracts interested fields into his/her system.
If you update server to return list with new object types, it will break de-serialization of that customer, even if he not interested in those new object types. That cause, that addition of new enum value breaks backward compatibility.
It definitely make sense, in cases where enums are big dictionaries(100+ values) and constantly updating to generate that as raw constants.
also, there is opposite case.
When you create custom package for customer with addition FieldType, but don't want to add it to client. All you want is just send them mail with "read with type value XXXX" message.
also#2, some android folks still recommends to use simple constants over enums.
There is workaround - you can change enum template to produce class with static constants.
public class {{classname}} {
{{#allowableValues}}{{#enumVars}}
{{#enumDescription}}
/**
* {{enumDescription}}
*/
{{/enumDescription}}
public static final {{{dataType}}} {{{name}}} = {{{value}}};
{{/enumVars}}{{/allowableValues}}
}
And run one more time generator using --import-model FieldType=Integer,Scenario=String addition options .
Uh oh!
There was an error while loading. Please reload this page.
There are some cases, when you want to generate enums as simple constants, to get move flexibility on future releases.
Let assume response body contains list of next object:
Your customer takes current version of client, parses that list, extracts interested fields into his/her system.
If you update server to return list with new object types, it will break de-serialization of that customer, even if he not interested in those new object types. That cause, that addition of new enum value breaks backward compatibility.
It definitely make sense, in cases where enums are big dictionaries(100+ values) and constantly updating to generate that as raw constants.
also, there is opposite case.
When you create custom package for customer with addition
FieldType
, but don't want to add it to client. All you want is just send them mail with "read with type value XXXX" message.also#2, some android folks still recommends to use simple constants over enums.
Additional context
@see swagger-api/swagger-codegen#6286
The text was updated successfully, but these errors were encountered: