BaseBlobService.get_blob_to_stream returns unusable Blob.content

[enricorotundo]

Which service(blob, file, queue) does this issue concern?

Blob

Which version of the SDK was used? Please provide the output of pip freeze.

azure-storage-blob==1.4.0
azure-storage-common==1.4.0
azure-storage-file==1.4.0
azure-storage-nspkg==3.0.0
azure-storage-queue==1.4.0

What problem was encountered?

import io
from azure.storage.blob.baseblobservice import BaseBlobService

blob_service = BaseBlobService(connection_string="...")
stream = io.BytesIO()
blob_file = blob_service.get_blob_to_stream("...", "...", stream=stream)

type(blob_file.content)

prints NoneType

What is the rationale for returning an empty Blob.content in this case? I should be able to use Blob.content, instead I'm required to pass a stream object and use that one, which appears inconsistent with the rest of the get_blob_* methods based on Blob.content (e.g. get_blob_to_text, get_blob_to_bytes.

[zezha-msft]

Hi @enricorotundo, thanks for reaching out! We really appreciate hearing your feedbacks.

It seems to me that get_blob_to_stream had to be different because we would like to enable more use cases, and it is supposed to be more general purpose than the other methods. For example, the user might want to process the data as it is getting written. Alternatively, the user might want to download to a specific type of stream. In fact, the other get_blob_to_* methods all leverage get_blob_to_stream.

I see that there's an inconsistency, where Blob.content is None for get_blob_to_stream. Do you have any suggestion for the expected behavior?

[far-authentise]

I would suggest Blob.content would returns a BytesIO object (or similar streaming object) to read the data from
That is similar behavior to some other companies (their name rhymes with 'Fan is on') returns on their ['body'] AttriDict value, when using a streaming function. Compared to, say ['body'] returning raw data, for the file version of the call.

[zezha-msft]

Hi @far-authentise, thanks for the feedback!

We are aware of the limitations and inconsistencies of the current design, and we are working on a new version of the SDK where these issues will be addressed. I'll update this thread once it's ready for preview.