Exposing Create and CreateAsync in collection that takes variable number of Creatables

[anuchandy]

No description provided.

[azuresdkci]

Can one of the admins verify this patch?

[azuresdkci]

Runtime changes detected. pull request created. CI running:

[martinsawicki]

I like it, but I'd like Jianghao to take a look as well.

[jianghaolu]

Looking good! It's cool that everyone gets the functionality for free.
Just one question, is there a scenario where something creatable is not batch creatable? In other words, can we merge SupportsBatchCreating into SupportsCreating?

[anuchandy]

Thanks jianghao, yes there is one scenario where a collection that exposes define(string name) cannot expose Create(Creatable<T>... creatables), the dependency graph requires all creatable resources are of type Resource. The Deployment is not a Resource. This is why we bound generic parameter of SupportsBatchCreation to Resource

public interface SupportsBatchCreation<ResourceT extends Resource> {
...
}

[jianghaolu]

@martinsawicki
Can you share the user scenario behind this feature? I was trying to understand the goal of this PR and that can't really go far without knowing the user scenario. Thanks!

[jianghaolu]

Also, one potential problem is for the async method. For sync methods, we have no problem calling:

List<VirtualMachine> vms = virtualMachines.create(vm1, vm2);

For async, this doesn't compile:

ServiceCall<List<VirtualMachine>> vmsFuture = virtualMachines.createAsync(vm1, vm2, null); // BTW, let's consistently keep callback as the last param since it's optional
/* do a bunch of stuff here */
List<VirtualMachine> vms = vmsFuture.get();

[anuchandy]

The async issue seems more general [i.e. storing the return value of async with return type ServiceCall<Derived> to a variable of type ServiceCall<Base> ]. For example if we use SDK like below, it compiles.

  ServiceCall<List<VirtualNetworkInner>> list = this.innerCollection.listAllAsync(null);

but not the below code, though List inherits from Collection

  ServiceCall<Collection<VirtualNetworkInner>> list1 = this.innerCollection.listAllAsync(null);

[Below code compiles]

  ServiceCall<VirtualNetworkInner> v = this.innerCollection.getAsync(null, null, null);

[below one not ]

  ServiceCall<com.microsoft.azure.Resource> v1 = this.innerCollection.getAsync(null, null, null);

VirtualNetworkInner inherits com.microsoft.azure.Resource

[martinsawicki]

@jianghaolu as far as the scenario question goes, the main thing I see with this is that I don't have to worry about asynch programming patterns to be able to take advantage of parallelism in the creation of independent resources. Our own automation test cases are a simple case of that --- to test aspects of an LB, a bunch of resources should already exist: VMs, PIPs, VNets. SO the test should pre-create them, but doing it all synchronously is very slow.

Exposing this on a collection of specific resources is a step toward the even more flexible scenario I think we could fairly easily enable as well -- of accepting a list of arbitrary Creatables from the user (via e.g. Azure#create(...)) and have the SDK parallelize it as needed. Since we already have that logic done internally, this should also be relatively simple to expose to users.

Ultimately, I can easily envision users pursuing a pattern (in such more complex multi-resource situations) of not calling individual <Resource>.create() at all, but only dealing with Creatables and passing them all to a single .create() at the end (or .createAsynch()).

This could perhaps marry the best of both worlds - the intuitiveness, familiarity and debuggability of the imperative synchronous programming model with the performance of the declarative and asynchronous ARM template model.
(It also has more of that Promise-like feel to it, where asynch operations are still ordered based on their dependency trees and failures can be handled in one place)

Just my thoughts on that.