refactor AccessEntry to use _properties
pattern
#1077
Labels
api: bigquery
Issues related to the googleapis/python-bigquery API.
type: process
A process-related concern. May include testing, release, or the like.
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:
or even
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
andentity_id
is reminiscent ofExternalConfig.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 forview
,routine
,dataset
, etc. These could accept and return relevant types (e.g. TableReference) as well.Existing
entity_type
andentity_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
The text was updated successfully, but these errors were encountered: