Description
I wonder if in the cases where BlobInfo
is not provided to Blob
we should actually get it from the service, and use empty if not exists (and document that).
My reason is, considering the following Blob
operations:
info
, exists
, content
, update
, delete
, copyTo
, reader
, writer
and signUrl
In all cases info matters if options are used (created #252 for exists
method) and in many cases info matters even without the options (e.g. info
, copyTo
).
Also, considering our example, I think this will make the API cleaner (and will not require
the explicit blob = blob.reload() pattern).
The reasons I think we don't want to force-get when BlobInfo is provided are:
- we don't want to double-reload when our API is returning the Blob. I guess we can get around that with a "special" constructor...
- That is the way for a user to force a new Info (e.g. for write).
Now when we clearly separate between blob identity and blob metadata, I think it is not
that unexpected that if one supply the metadata we should respect it as is (though documentation should make it clear).
This issue was discussed in #251 and @mziccard suggested that instead of getting the info in the identity constructors (BlobId
or bucket & name) to provide a Blob.fetch(storage, identity)
methods and only have one constructor that accepts BlobInfo
(no force loading in that one).
I am in favor of the above suggestion though maybe we should name it load
to be consistent with the existing reload
.