[Storage][Webjobs] Bind to BlobClient #16336
Conversation
ghost
added
the
kasobol-msft
requested review from
amishra-dev,
amnguye,
fabiocav,
seanmcc-msft and
tg-msft
as code owners
| context.AddConverter(new StorageBlobConverter<AppendBlobClient>()); | ||
| context.AddConverter(new StorageBlobConverter<BlockBlobClient>()); | ||
| context.AddConverter(new StorageBlobConverter<PageBlobClient>()); | ||
| context.AddConverter<BlobBaseClient, BlobClient>(ConvertBlobBaseClientToBlobClient); |
There was a problem hiding this comment.
When would this converter be invoked?
There was a problem hiding this comment.
There are two cases:
- When somebody binds to collection of blobs using
[Blob] IEnumerable<BlobClient>here. In this case this will go through "identity conversion" (i.e. it will already resolve correct type few lines above). - The second one is if someone uses
[BlobTrigger] BlobClient. In that case the trigger may receive "invoke string" (which is basically blob path) or this which is coming from here.
Now that you ask this question I can see that in first case we could replace this converter with new StorageBlobConverter<BlobClient>() which basically type casts and validates that resolved type matches requested type. That'd be doable as we already know target type.
If we pursue that I think it would be good to move converter registrations from context to each rule so that [Blob] and [BlobTrigger] have their own sets of converters defined separately (even if it means small duplication).
As for the second case. We won't get rid of that converter as at the time the client is resolved we don't know the target type, so we can't make a decision whether to resolve BlobClient or BlockBlobClient. Hence conversion BlockBlobClient->BlobClient or BlobClient ->BlockBlobClient (if we swap everything) is going to be somewhere.
Let me know what you think.
There was a problem hiding this comment.
I went ahead and made these changes. Life would be easier if we could traverse from XBlobClient to ContainerClient like we could in V11.
| public BlobCollectionConverter(BlobsExtensionConfigProvider parent) | ||
| { | ||
| IConverterManager cm = parent._converterManager; | ||
| var type = typeof(T); |
There was a problem hiding this comment.
thanks. removed.
* can bind [Blob] to BlobClient. * this works. * update snippet to use blobclient. * remove todo. * add doc strings. * scope new converter to blobtrigger. * remove unused part.
5 participants
This PR adds ability to bind to BlobClient.
BlobClient is the simplest BlobClient the Storage SDK offers. It has all BlobBaseClient functionality as well as uploads that are backed by block blobs. Therefore it can be also seen as simplified version of BlockBlobClient.
The challenging part is that both BlobClient and BlockBlobClient are valid choices if blob exists and has blobType=Block, so there's ambiguity when reference is resolved with type check if blob exists. Additionally Blob And BlobTrigger attributes have somewhat different dataflow.
I ended up resolving to BlobClient if target type is known and adding converter to handle other cases.
Test coverage added: