[Discussion] Support for inline and non-inline external child resources

[anuchandy]

External child resources:

The child resources that requires separate call to perform CUD on it i.e. they cannot be created, updated or deleted by doing a PUT/POST on parent resource.

Current base classes:

Today the types ExternalChildResourceImpl and ExternalChildResourcesImpl are used to enable create, update and delete operations of external child resources as part of parent resource create or update flow.

i.e. these types enables following flows:

    parentResources().define(name)
        .defineChildResource(c1)
            .withProperty1Value(p1)
            .withProperty2Value(p2)
            .attach()
        .defineChildResource(c2)
            .withProperty1Value(p1)
            .withProperty2Value(p2)
            .attach()
        .create();


    parentResource.update()
        .defineChildResource(c3)
            .withProperty1Value(p1)
            .withProperty2Value(p2)
            .attach()
        .updateChildResource(c1)
            .withProperty1Value(p1)
            .withProperty2Value(p2)
            .parent()
        .withoutChildResource(c2)
        .create();       

The main advantages of this pattern are:

1. By allowing user to specify operations on multiple children in a single statement, ExternalChildResourcesImpl can parallize these operations.
2. The definitions flow of children looks more natural to the user, to an extend from user we can hide the fact that these are external child resources.

inline external child resources:

So far the external child resources we encountered are present in the parent payload, i.e. no seperate call is required to fetch them. ExternalChildResourcesImpl is implemented based on this assumption.

e.g. [VirtualMachine, Extensions], [TrafficManagerProfile, endpoints], [Batch, Applications]

non-inline external child resources:

Recently we came across some models (e.g. parent: DnsZone, child:RecordSets) where external child resources are not present in the parent payload and requires a seprate call to fetch them.

e.g. [DnsZone, RecordSets]

Why current ExternalChildResourcesImpl not suitable for non-inline external child resources

Though the current ExternalChildResourcesImpl can be used for new models, using it requires a seperate list call to be made which is an overhead if the child resources are paged.

Solution:

To enable us to handle these two types of models (inline vs non-inline) we are splitting ExternalChildResourcesImpl into two

1. ExternalChildResourcesCachedImpl - targets inline case, i.e. children is a collection property of parent

2. ExternalChildResourcesNonCachedImpl - target non-inline case, i.e. no property in parent that hold child collection

These two types derive from ExternalChildResourceCollectionImpl which is responsible for performing operations on children in parallel, throwing aggreate exception if one or more operations fails.

See the implementation of these types in the PR: #1262

[anuchandy]

This is done, hence closing.