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
Introduce partial resources for cross RP resource references (#2229)
* add configuration for virtual resources
* add a new layer in inheritance hierarchy VirtualResource. Resource now stands for ConcreteResource and inherits from VirtualResource
* add a new test project about virtual resources
* reverse the inheritance between Resource and VirtualResource
* now we could add virtual resource to resource list
* implement virtual resources
* update test swagger
* update to virtual resource
* fix broken test cases
* add test cases
* update test cases
* rename virtual resource to partial resource
* change the create resource identifier to internal in partial resource
* fix
* some refinement and documentation
* now you can override the name of a partial resource like a normal resource
* modify the description of partial resource accordingly
* fix test cases
* minor fix after merge
* regenerate the new test project
* regenerate
* refactor and regenerate
* add a comment to explain the override
* refactor
* regenerate test projects
* fix a few issues
Some operations might be operations of a resource from another RP, or some resources might have a parent resource from another RP.
632
+
633
+
For instance, in the RP `compute`, we have a resource `VirtualMachine` with the path of `/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/virtualMachines/{vmName}`, in the meantime, in the RP `network`, which is completely a different SDK, we have an operation with the path of `/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/virtualMachines/{vmName}/publicIps` which is clearly listing something on the virtual machine. During the generation of network RP, the generator has no knowledge of the resources in another RP, therefore by default this operation will be generated like the following code as an operation on the `ResourceGroupResource` because this is the best parent the generator could find within this RP.
634
+
```csharp
635
+
public static partial class NetworkExtensions
636
+
{
637
+
public static Pageable<PublicIPAddress> GetPublicIPs(this ResourceGroupResource resourceGroup, string vmName)
will tell the generator that this path `/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/virtualMachines/{vmName}` is also a valid resource, and the generator will put it into the list of its known resources, and generates a "partial resource" from it and the operation in above example will show up here:
650
+
```csharp
651
+
public partial class VirtualMachineNetworkResource
652
+
{
653
+
public virtual Pageable<PublicIPAddress> GetPublicIPs()
654
+
{
655
+
/* the implementation */
656
+
}
657
+
}
658
+
```
659
+
660
+
The naming pattern of a partial resource is like `[ResourceName][RPName]Resource`, where `ResourceName` is the value you assigned in the configuration, `RPName` is the name of this RP (for instance, `Network`). The name of a partial resource is also configurable using the `request-path-to-resource-name` configuration, please see [change resource name](#change-resource-name) section for more details.
661
+
662
+
The difference between a normal resource and a partial resource is that the partial resource is not a concrete resource, therefore it does not have a corresponding collection, and you cannot get the list of it from its direct parent (ResourceGroupResource in the above example).
663
+
But like normal resources, partial resources will have an extension method of `Get[PartialResourceName]` on the `ArmClient` to let you get it from its full Id.
664
+
628
665
### Scope resources
629
666
630
667
Some resources are scope resources, which means that these resources can be created under different scopes, like subscriptions, resource groups, management groups, etc. In the swagger, we currently do not have an extension which assigns which type of resources can be the scope of this resource, therefore we add a configuration in our generator `request-path-to-scope-resource-types` for this new information.
//TODO handle expandable request paths. We assume that this is fine since if all of the expanded
218
218
//types use the same model they should have a common name, but since this case doesn't exist yet
219
219
//we don't know for sure
220
220
if(requestPath.IsExpandable)
221
221
thrownewInvalidOperationException($"Found expandable path in UpdatePatchParameterNames for {operationGroup.Key}.{operation.CSharpName()} : {requestPath}");
0 commit comments