Rely on CloudBlob.BlobType rather than blob concrete type about azure-storage-net-data-movement HOT 5 OPEN

The reason datamovement library internally depends on the concrete type is it varies in how it read/writes data for different type of blob and the read/writes interface only exists in the concrete type of CloudBlob.

I agree the library can include the type cast codes you posted and somehow have a more convenient interface. However, given the destination blob may doesn't exists at all, it's impossible to find the blob type by datamovement library itself. Thus, we prefer to leave it for the caller to provide the concrete type to keep the logic simple.

from azure-storage-net-data-movement.

The motivation is clear, you cannot know the destination type if the developer doesn't provide it.
But all I'm saying that the type can be also known when the library will be provided with the base class CloudBlob, using its CloudBlob.BlobType property.

That means that if the developer will provide the base class (without resolving its concrete type), the library can rely on the BlobType property, for both the source and destination, instead of checking the concrete type.

Thus, the library can check:
if (destinationBlob.BlobType == BlobType.BlockBlob)
instead of
if (destinationBlob is CloudBlockBlob)

from azure-storage-net-data-movement.

Make sense. I was thinking not to add codes to fetch the blob type from server since BlobType in CloudBlob can be unspecified and not always possible to fetch.

One more question is how you end up with a CloudBlob instance with concrete BlobType property instead of a CloudPageBlob/CloudBlockBlob/CloudAppendBlob? Usually if user don't care about the blob type, it means he/she get the instance from server with either ListBlobs or GetBlobReferenceFromServer. Both of them will return the blob instance with concrete type. The only way I know is use GetBlobReference and call FetchAttributes on the returned blob, which can be replaced with GetBlobReferenceFromServer.

from azure-storage-net-data-movement.

My scenario is that I'm getting a blob uri including sas from my users, and simply initializing CloudBlob object as follows:
CloudBlob blob = new CloudBlob(blobUriWithSas);

I'm agnostic to the blob type and thus thought that having TransferManager agnostic will be helpful, saving the developer the need to use the 'switch' block I mentioned above.

from azure-storage-net-data-movement.

I encountered the same issue when using TransferManager.DownloadAsync, cf #184 .

from azure-storage-net-data-movement.