Skip to content

Change Blob to eagerly get a BlobInfo if constructed with only id. #253

Closed
@aozarov

Description

@aozarov

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.

Metadata

Metadata

Assignees

Labels

🚨This issue needs some love.api: storageIssues related to the Cloud Storage API.triage meI really want to be triaged.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions