The Bucket API resource representation defines a number of fields as "writable", but which we don't already map:
- cors[]
- lifecycle{}
- location
- logging{}
- versioning{}
The support for the website{} field is slightly odd (Bucket.configure_website / Bucket.disable_website), and should likely be normalized with support for the other fields.
Bucket.from_dict currently captures them all in the key's metadata attribute, but that name creates confusion with its metadata key (which stores application-defined key-value pairs).
I think it would be cleaner to map each the non-user-defined fields onto separate attributes, and propagate them to the server via the insert, and patch or update endpoints.
Bucket should also expose read-only properties for the non-writable resource fields not already mapped, and which aren't constants:
- etag
- id
- metageneration
- name
- owner{}
- projectNumber
- selfLink
- storageClass
- timeCreated
Reactions are currently unavailable
The Bucket API resource representation defines a number of fields as "writable", but which we don't already map:
The support for the website{} field is slightly odd (Bucket.configure_website / Bucket.disable_website), and should likely be normalized with support for the other fields.
Bucket.from_dict currently captures them all in the key's metadata attribute, but that name creates confusion with its metadata key (which stores application-defined key-value pairs).
I think it would be cleaner to map each the non-user-defined fields onto separate attributes, and propagate them to the server via the insert, and patch or update endpoints.
Bucket should also expose read-only properties for the non-writable resource fields not already mapped, and which aren't constants: