I was reviewing the Storage AIO PR, and found something that concerns me a little:
We have several client:
- BlobServiceClient
- BlobClient
- ContainerClient
From a BlobServiceClient, you can receive a BlobClient using “get_blob_client”. “get_blob_client” will create a BlobClient by sharing the same “pipeline”.
This means this code:
with BlobServiceClient(….) as bsc:
with bsc.get_bloc_client() as bc:
# pass
Will call twice the aenter and aexit on the transport. That already could be a problem, but if you do code still like this, that starts to become really unhealthy for you:
with BlobServiceClient(….) as bsc:
with bsc.get_bloc_client() as bc:
# pass
bsc.get_account_information() # transport closed!
Discussing with @johanste , we don't want reference count to enable scenario like "I create BlobServiceClient, from which I create a ContainerClient, from that I create the BlobServiceClient and it stills work".
Current proposal would be if you create a local client from an upper client, the upper client owns the pipeline (or the transport at least) and you need to close them in the correct order.
I was reviewing the Storage AIO PR, and found something that concerns me a little:
We have several client:
From a BlobServiceClient, you can receive a BlobClient using “get_blob_client”. “get_blob_client” will create a BlobClient by sharing the same “pipeline”.
This means this code:
Will call twice the aenter and aexit on the transport. That already could be a problem, but if you do code still like this, that starts to become really unhealthy for you:
Discussing with @johanste , we don't want reference count to enable scenario like "I create BlobServiceClient, from which I create a ContainerClient, from that I create the BlobServiceClient and it stills work".
Current proposal would be if you create a local client from an upper client, the upper client owns the pipeline (or the transport at least) and you need to close them in the correct order.