Azure / autorest.powershell

AutoRest PowerShell Generator
MIT License
111 stars 76 forks source link

[Feature Request] Support Model Type Names with Namespace in `model-name` #1191

Open peombwa opened 1 year ago

peombwa commented 1 year ago

Directives that use model-name to "filter a model" should also support model type names with namespaces. For example, we should be able to define a table formatting directive that has "namespaced" type name to set the table format for a model type as shown below:

directive:
  - where:
      model-name: Org.MyService.Namespace.TypeName
    set:
      format-table:
        properties:
          - DisplayName
          - Id
          - Mail
          - UserPrincipalName
dolauli commented 1 year ago

@peombwa There should be one namespace configured, why there are two different namespaces in your case.

peombwa commented 1 year ago

Per our existing architecture, we have a centrally managed table formatting directive config that is shared across multiple modules (namespaces). The modules use the same types, so it made sense to manage the default format centrally. Each namespace/API version returns a different set of properties that we would like to differentiate by namespaces in our centrally managed table formatting directive config, hence the feature request:

  - where:
      model-name: Org.MyService.v1.TypeName
    set:
      format-table:
        properties:
          - DisplayName
          - Id
          - Mail
          - UserPrincipalName
  - where:
      model-name: Org.MyService.beta.TypeName
    set:
      format-table:
        properties:
          - DisplayName
          - Id
          - Mail
          - UserType

I'm aware that we can look at splitting the directive config into each module, but this will lead to duplication of directives since we have several modules.

dolauli commented 1 year ago

@peombwa This seems to be out of the scope what autorest.powershell should support. For your case, those types actually contain different properties in different namespaces/modules which should not be in a share config, so just as you said you should splitting those directives in each modules.