resource model changes of generated SDK code based on TSP compared with swagger

[msyyc]

By comparing diff about generated SDK between TSP and swagger, I find some model name changes:

• Resource-> ArmResource
• ProxyResource-> ProxyResourceBase
• TrackedResource-> TrackedResourceBase

I think it is related with tsp definition of tyepsec-azure-resource-manager

[allenjzhang]

Is this the exhaust list? @@projectedName should be used to adjust client name.

[tadelesh]

Workaround: review all TSP ARM model and rename them with @projectedName according to the name in common types.

[markcowl]

If we are going to support very old APIs, there are several possible patterns:

• Resource is defined in the spec
• Resource types inherit from 'Resource' or similar common schema
• Resource types inherit from another common schema (e.g. ProxyResource, even if they are tracked resources)

If client generation is sensitive to inheritance from common-types, thenthe right things likely is to generate the proper inheritance in this case and not use the resource templates, the template constraints use structural typing, not nominal typing, so any model with the right properties will work as in this playground

[tadelesh]

@markcowl thanks for your solution for non-standard resource definition.

Two concerns for the standard resource:

1. When sdk emitter get models info directly from tsp, we will get ProxyResourceBase as the base model, which name is different from swagger definition, thus will cause breaking changes for brown field RPs.
2. I don't see different version's common types defined in arm lib. Could sdk emitter get different properties info according to @armCommonTypesVersion setting directly from tsp compile?

[markcowl]

@tadelesh Those types also have an @armCommonTypes definition - the generator should be making these decisions for compliant specs by the ARM common types definition, so this decorator may be useful in the 'compliant' case.

There are differences in the common types version, strictly around type formats (resourceId, uri, uuid), there have not, to date been any substantial differences other than these

[markcowl]

The solution we have discussed is:

• Rename the types in the inheritance chain for ProxyResource, TrackedResource and ExtensionResource, so these align with common type schema names
• Add models matching other resource types in common schema for use when defining non-standard (not ProxyResource or Trackedresource) inheritance.

[allenjzhang]

#762