MM shouldn't generate redundant name for expand and flatten function

[neil-yechenwei]

Current Name : expandArmPrivateLinkServicePrivateLinkServicePropertiesAutoApproval Expect Name : expandArmPrivateLinkServicePropertiesAutoApproval Current Name : flattenArmPrivateLinkServicePrivateLinkServicePropertiesAutoApproval Expect Name : flattenArmPrivateLinkServicePropertiesAutoApproval

[houkms]

Coding style issue, we need to shorten the function name.

[magodo]

The rule used here is defined here, illustrated below:

<%= sdk_marshal.resource -%><%= descriptor.func_name -%>

Where:

• sdk_marshal.resource equals to: "Arm" + Api::Resource.name (accroding to this and this)
• descriptor.func_name equals to: Api::Azure::SDKTypeDefinition.go_type_name(according to this)

From my understanding, this naming convention make sense. Because currently the folder structure of azure provider code is using flatten pattern, i.e., all resource source files are within same package. Hence:

• To avoid name conflict between different resource, we have to specify Api::Resource.name as part of flatten/expand func name
• To avoid name conflict for same resource, but for different data type, we hanve to specify the target go type's name, i.e. Api::Azure::SDKTypeDefinition.go_type_name as part of flatten/expand func name

For this specific case, the private link service api.yaml is illustrated below:

...
objects:
  - !ruby/object:Api::Resource
    name: PrivateLinkService
    ...
    azure_sdk_definition: !ruby/object:Api::Azure::SDKDefinition
      create: !ruby/object:Api::Azure::SDKOperationDefinition
          ...
          '/properties/autoApproval': !ruby/object:Api::Azure::SDKTypeDefinition::ComplexObject
            ...
            go_type_name: PrivateLinkServicePropertiesAutoApproval

IMHO, I think we can introduce a toggle in TF override logic, which is on by default, which will will concat function name in a compact way. In case of a resource has several similar type, one of which has prefix as resource name so as to avoid conflict, then we should turn this toggle off.

@houkms how do you think?

[houkms]

@magodo Makes sense.