Add support for new GCS collection doc versions #675
Conversation
Support versions '1.6.0' and '1.7.0' via `guest_auth_policy_id` and long `user_message` handling. Internally, the `guest_auth_policy_id` is simply a mapped-collection-only field matching the current structure, but the `user_message` treatment requires a new structure. DocumentWithInducedDatatype now defines `DATATYPE_VERSION_CALLBACKS` as a secondary versioning mechanism alongside the `DATATYPE_VERSION_IMPLICATIONS` mapping. The callbacks take the entire object and return an optional version number tuple. This is an extremely generic way of allowing a callback to apply arbitrary criteria for the version numbering. In service of that change, the protocol now requires `__getitem__` (trivially satisfied by all instances) so that the contents can be checked. The callbacks are defined as a classvar tuple.
sirosen
requested review from
aaschaer,
ada-globus,
derek-globus and
kurtmckee
as code owners
|
|
||
| def __contains__(self, key: str) -> bool: # pragma: no cover | ||
| ... | ||
|
|
||
| def __setitem__(self, key: str, value: t.Any) -> None: # pragma: no cover | ||
| ... | ||
|
|
||
| def __getitem__(self, key: str) -> t.Any: # pragma: no cover | ||
| ... | ||
|
|
There was a problem hiding this comment.
A brief note for reviewers:
I'm well aware that this protocol looks like it could inherit from Mapping. I've avoided making that change for two basic reasons:
- I don't fully know what the implications are of protocol inheritance (normal class inheritance rules?)
- Protocols are a way of getting non-inheritance based polymorphism. Using inheritance to define them strikes me instinctively as wrong, although maybe it's fine.
On both points, I'm mostly unsure and avoiding the issue for now.
| storage_gateway_id: t.Optional[UUIDLike] = None, | ||
| # strs | ||
| domain_name: t.Optional[str] = None, | ||
| guest_auth_policy_id: t.Optional[UUIDLike] = None, | ||
| storage_gateway_id: t.Optional[UUIDLike] = None, |
There was a problem hiding this comment.
It looks like these type-based comment markers (# strs, # str lists) are becoming inaccurate.
There was a problem hiding this comment.
I'm not sure if they're useful or not, but I meant "is a string in the payload" (rather than the types accepted by the SDK helper). So the storage_gateway_id moved in part to try to make it accurate again.
Like I said, I'm not really sure if this is useful. I'm just trying to give us some handle for looking through these (long!) lists of arguments.
Support versions '1.6.0' and '1.7.0' via
guest_auth_policy_idand longuser_messagehandling.Internally, the
guest_auth_policy_idis simply a mapped-collection-only field matching the current structure, but theuser_messagetreatment requires a new structure.DocumentWithInducedDatatype now defines
DATATYPE_VERSION_CALLBACKSas a secondary versioning mechanism alongside theDATATYPE_VERSION_IMPLICATIONSmapping. The callbacks take the entire object and return an optional version number tuple. This is an extremely generic way of allowing a callback to apply arbitrary criteria for the version numbering. In service of that change, the protocol now requires__getitem__(trivially satisfied by all instances) so that the contents can be checked.The callbacks are defined as a classvar tuple.