Remove StorageClient from azure_storage_queues
#1074
Conversation
There was a problem hiding this comment.
Maybe not something to address in this PR, but I am not convinced that all of these url construction functions should actually be fallible. In many cases it seems like if they can't actually construct a valid URL they should actually panic. In most cases they aren't really using information provided by the caller anyway, so I am not really sure how you could even recover from the error.
| pub(crate) fn finalize_request( | ||
| &self, | ||
| url: url::Url, | ||
| method: azure_core::Method, | ||
| headers: azure_core::headers::Headers, | ||
| request_body: Option<azure_core::Body>, | ||
| ) -> azure_core::Result<Request> { | ||
| self.client | ||
| .finalize_request(url, method, headers, request_body) | ||
| } |
There was a problem hiding this comment.
Question: Are there any cases where this isn't delegated? If not why not just have one shared function? It may also match similar usages in storage_blob, so maybe they can all shared one function?
There was a problem hiding this comment.
Yea, this probably makes sense.
There was a problem hiding this comment.
On second thought I'd like to do this in a separate PR.
|
@gorzell the urls use the account name which is user provided - we could check at construction that the username is url safe and then not have to return fallible url methods, but I would leave that for a follow-up. |
3 participants
This is the next step in the process of removing
StorageClientfollowing #1062 and #1057.Creating the various clients in
azure_storage_queuesnow mirrors how things work with blob storage, data lake, and cosmos.