Can't delete custom metadata key on object

[hankd-v]

I ran into some issues trying to delete a custom metadata key from a storage object. I expected the following to work, but did not result in the key being deleted:

# blob has metadata with key 'foo'
new_metadata = {}
for x in blob.metadata:
    if x != 'foo':
        new_metadata[x] = blob.metadata[x]
# new_metadata is now a copy of the metadata without key 'foo'
blob.metadata = new_metadata
blob.patch()
# The blob's metadata still has key 'foo'

The Rest API indicated to send a value of JSON null associated with the key to perform a deletion, but that doesn't seem to happen when issuing a blob.patch with a metadata with a key removed.

As a work around, I created a copy of the desired metadata, deleted all of the blob's metadata (which does work), then updated the metadata to be the desired metadata.

new_metadata = {}
for x in blob.metadata:
    if x != 'foo':
        new_metadata[x] = blob.metadata[x]
blob.metadata = None
blob.patch()
blob.metadata = new_metadata
blob.patch()

[tritone]

I was able to reproduce the issue from your example.

I think it's expected that deleting a key would not succeed in overwriting the key when using a patch request. However, I would think that at least by setting a key's value to None, it would be possible to indicate that the key should be deleted by sending null to the API. However, this also fails because of this line here:

python-storage/google/cloud/storage/blob.py

Line 3629 in fdabd6a

value = {k: str(v) for k, v in value.items()}

-- converting the value to a string means that None is stored as "None"!

I tested locally and by rewriting the line as follows, we can allow keys to be deleted by setting their value to None:

            value = {k: str(v) if v is not None else None for k, v in value.items()}

@frankyn @andrewsg does this seem like the correct approach to you? If so I'll make a PR (and add it to the docs for metadata that this is how keys can be deleted).

[frankyn]

I'm surprised we hadn't seen this before to be honest, but yes, the suggestion LGTM!