[Storage] get_blob_properties for BlobClient
#2014
Conversation
vincenttran-msft
requested review from
heaths,
RickWinter,
JeffreyRichter,
LarryOsterman and
ronniegeraghty
as code owners
vincenttran-msft
changed the title
get_blob_properties initial implementationget_blob_properties for BlobClient
sdk/storage/azure_storage_blob/src/pipeline/storage_headers_policy.rs
Outdated
Show resolved
Hide resolved
sdk/storage/azure_storage_blob/src/pipeline/storage_headers_policy.rs
Outdated
Show resolved
Hide resolved
|
Hi @heaths Heath, I have documented the remaining 4 feedback items into my notes, and will address them in the following PR. I have commented out the testcases since they currently rely on static resources and have a hard dependency on some NYI functionality. With that in mind- please let me know if there is any other showstoppers in this specific PR. Thanks! |
| client: GeneratedBlobClient, | ||
| } | ||
|
|
||
| impl BlobClient { |
There was a problem hiding this comment.
In other languages, I thought you can only get a BlobClient from a ContainerClient or something i.e., these aren't creatable. If so, they must be exported from both the crate root (re-exported) and from the clients module in which all clients - creatable or gettable - are exported.
There was a problem hiding this comment.
Nope, you can construct these independently (python ex.):
https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/storage/azure-storage-blob/tests/test_blob_client.py#L82
| pub(crate) use blob_client::BlobClient as GeneratedBlobClient; | ||
|
|
||
| pub use blob_client::BlobClient; | ||
| pub use crate::generated::clients::blob_blob_client::BlobBlobClientGetPropertiesOptions; | ||
| pub use crate::generated::clients::blob_client::BlobClientOptions; |
There was a problem hiding this comment.
Why export them from the root for the crate? Just have the modules within the crate import crate::generated::clients::BlobClient. Re-exporting types only for the crate like this is going to lead to a lot of confusion, I think. It's not typical.
There was a problem hiding this comment.
So for L16 pub(crate) use blob_client::BlobClient as GeneratedBlobClient;, I can change this to in-line importing:
generated::clients::blob_client::BlobClient as GeneratedBlobClient
wrt L18-19, I re-exported them because I thought we wanted all client options accessible from the root (guidelines section). Without re-exporting them, we would have to import them as:
use crate::generated::{BlobClientOptions, BlobBlobClientGetPropertiesOptions};| impl FromHeaders for BlobProperties { | ||
| type Error = url::ParseError; | ||
|
|
||
| fn header_names() -> &'static [&'static str] { |
There was a problem hiding this comment.
I was a little confused when trying to pattern match this-- is this supposed to be an exhaustive list of the possible optional headers? For now, I only had the plain-text version of the headers I had to create a new const for.
| pub content_type: String, | ||
| pub creation_time: String, | ||
| pub etag: String, | ||
| pub last_modified: String, |
There was a problem hiding this comment.
wrt this comment, is there a currently accepted way to convert from RFC1123 strings (as returned by the service) ex:
creation_time: Some("Sat, 01 Feb 2025 00:17:37 GMT" to a OffsetDateTime object? I know you can provide a custom pattern query to parse, but I assume that if we have OffsetDateTime elsewhere we may have some common utility for this?
|
I was under the impression this PR was no longer passing due to merging in |
This PR contains the following:
BlobClientto supportget_blob_propertiesget_blob_propertiesand simple test cases (get properties with existing blob, container not exists case)