-
Notifications
You must be signed in to change notification settings - Fork 323
Description
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