storage: Missing fields while migrating from `google.golang.org/api/storage/v1`

[karanpopat]

Client

Storage

Go Environment

go version go1.20.3 darwin/arm64

Expected behavior

The bucket API should be returning these fields along with others in the response

ID
OwnerEntity
SelfLink
Updated

The object API should be returning these fields in addition to the others

ID
SelfLink
TimeStorageClassUpdated

Actual behavior

While migrating from storage API in "google.golang.org/api/storage/v1" to "cloud.google.com/go/storage" There are a few fields missing in the new API.

These are the columns that are missing in the new get bucket API.

OwnerEntity
SelfLink
Updated

Columns missing in the get object API

SelfLink
TimeStorageClassUpdated

Additional context

Switching from cloud.google.com/go/storage v1.27.0 to cloud.google.com/go/storage v1.31.0

[tritone]

I believe this is related to moving from "google.golang.org/api/storage/v1" to "cloud.google.com/go/storage", NOT to updating the version of cloud.google.com/go/storage to v1.31.0, correct?

Can you clarify the use cases for including these fields? I believe most of them should either not be relevant to client library users (e.g. selfLink is a JSON API concept, you would never use it to access the object via the client library) and/or can be constructed easily from other fields (e.g "ID" is just // and is also something that the client library doesn't consume. We are reluctant to expose additional fields which are not relevant to client library users.

Let me know what you think.

[cbruno10]

Hi @tritone , I work with @karanpopat on the GCP plugin for a product called Steampipe. Our goal with the plugin is to offer SQL tables that users can use to query their GCP resources, e.g., for Storage buckets, https://hub.steampipe.io/plugins/turbot/gcp/tables/gcp_storage_bucket.

In each table, we create columns to match API fields. We're not always sure how users will use each property, but try to make as many properties available as possible to satisfy different use cases.

For the ID and SelfLink fields, I believe we can construct those using other response info. But for the bucket's OwnerEntity and Updated fields and object's TimeStorageClassUpdated, I don't believe we can get that info from any other fields. These don't seem like the most crucial fields, but nice to have when searching for recent updates and owner information.