And this is what the generated parameters look like:
Issues with current behavior
Notice how encryption.type from the json body became --type in the parameters, but identity.type became --video-analyzer-identity-type. Autorest.az seems to be assigning a prefix to a repeat parameter name. This is an issue because what if in the future the ordering of our properties in our swagger changes or another property named type gets added? Then the generated names will be different based on what property comes first. This can cause breaking changes in our users' scripts.
Notice how in the parameters we have --user-assigned-identity (under Encryption Identity Arguments), --user-assigned-identities (under Identity Arguments), and user-assigned-identity (under --storage-accounts). The only difference between these parameter names is one is singular and the other is plural. This is very ambiguous and can be confusing to customers.
Proposal for new generation option for parameter names
In order to combat these issues, we would like to propose a generation option that can define parameters using their fully qualified json path. To clarify, we are not asking for this to be the default mode during generation; rather have it be enabled through a flag.
What I mean by fully qualified json path:
For the property encryption.type: change --type to --encryption-type.
For the property identity.type: change --video-analyzer-identity-type to --identity-type.
For the property identity.userAssignedIdentities, change --user-assigned-identities to --identity-user-assigned-identities.
And so on.. this naming structure would apply for every property. This will create more clear names and be less confusing to the user as to which group the parameters belong to. This will also avoid breaking changes if the order of the swagger changes.
It appears the capabilities for this feature does exist since currently if Autorest.Az comes across a repeated property name it will append the entity name (--video-analyzer-identity-type)
Current behavior
This is how our video analyzer entity is defined:
And this is what the generated parameters look like:
Issues with current behavior
encryption.type
from the json body became--type
in the parameters, butidentity.type
became--video-analyzer-identity-type
. Autorest.az seems to be assigning a prefix to a repeat parameter name. This is an issue because what if in the future the ordering of our properties in our swagger changes or another property namedtype
gets added? Then the generated names will be different based on what property comes first. This can cause breaking changes in our users' scripts.--user-assigned-identity
(under Encryption Identity Arguments),--user-assigned-identities
(under Identity Arguments), anduser-assigned-identity
(under--storage-accounts
). The only difference between these parameter names is one is singular and the other is plural. This is very ambiguous and can be confusing to customers.Proposal for new generation option for parameter names
In order to combat these issues, we would like to propose a generation option that can define parameters using their fully qualified json path. To clarify, we are not asking for this to be the default mode during generation; rather have it be enabled through a flag.
What I mean by fully qualified json path:
encryption.type
: change--type
to--encryption-type
.identity.type
: change--video-analyzer-identity-type
to--identity-type
.identity.userAssignedIdentities
, change--user-assigned-identities
to--identity-user-assigned-identities
.And so on.. this naming structure would apply for every property. This will create more clear names and be less confusing to the user as to which group the parameters belong to. This will also avoid breaking changes if the order of the swagger changes.
It appears the capabilities for this feature does exist since currently if Autorest.Az comes across a repeated property name it will append the entity name (
--video-analyzer-identity-type
)