Skip to content

refactor AccessEntry to use _properties pattern #1077

@tswast

Description

@tswast

Is your feature request related to a problem? Please describe.

Often there is a private preview feature (or just a new feature that we haven't implemented yet) and we want to provide our customers a workaround to be able to send a resource as represented by JSON. Then we could have provided a workaround to the user in #1064 like the following:

entry = AccessEntry.from_api_repr({
  "role": "READER",
  "dataset": {
    "projectId": "project-id",
    "datasetId": "dataset_id",
  }
})

or even

entry = AccessEntry("READER")
entry._properties["dataset"] = {
    "projectId": "project-id",
    "datasetId": "dataset_id",
}

and been confident that it would send the correct values when making the API request.

Likewise, one could read values from the API like entry._properties["dataset"] when checking values from the API.

Describe the solution you'd like

The way we handle entity_type and entity_id is reminiscent of ExternalConfig.options, which I refactored in #994. It was clever at the time when there were only a few external data formats, but has diverged far the actual API representation.

AccessEntry should have separate properties for view, routine, dataset, etc. These could accept and return relevant types (e.g. TableReference) as well.

Existing entity_type and entity_id should be made optional in the constructor, but in the same order so that backwards compatibility is maintained.

Describe alternatives you've considered

Leaving the class as-is should continue to work, but it's a significant risk IMO.

Additional context

As identified in #1075

See similar work in #994

Metadata

Metadata

Assignees

Labels

api: bigqueryIssues related to the googleapis/python-bigquery API.type: processA process-related concern. May include testing, release, or the like.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions