Is your feature request related to a problem or challenge? Please describe what you are trying to do.
I'd like to use object_store to store blobs (and stay somewhat cloud-provider agnostic).
Depending on the size/nature of the blob, I either break it further down, or store it as-is. I need to distinguish these two cases when reading the data back in, and I'd like to use the widely-supported content-type field for this (it's either application/octet-stream, or some index content-type).
The decision of which content-type to use can't be made statically, but needs to happen per request. Which means the existing content-type mechanism (default, or map from extension to content-type) is not sufficient.
Describe the solution you'd like
Add an optional content_type field to PutOptions. In case it's not None, use that content type in favor of any of the existing logic.
Additionally, add an optional content_type field to ObjectMeta. Most backends already send the content type anyways, so populating it should be quite limited in cost, and no explicit different client config should be necessary.
Describe alternatives you've considered
Using custom metadata, as introduced in apache/arrow-rs#4999. This however is distinct from content-type and requires an additional request for some backends (AWS), while content-type is sent inline alongside the data.
Is your feature request related to a problem or challenge? Please describe what you are trying to do.
I'd like to use
object_storeto store blobs (and stay somewhat cloud-provider agnostic).Depending on the size/nature of the blob, I either break it further down, or store it as-is. I need to distinguish these two cases when reading the data back in, and I'd like to use the widely-supported content-type field for this (it's either application/octet-stream, or some index content-type).
The decision of which content-type to use can't be made statically, but needs to happen per request. Which means the existing content-type mechanism (default, or map from extension to content-type) is not sufficient.
Describe the solution you'd like
Add an optional
content_typefield toPutOptions. In case it's notNone, use that content type in favor of any of the existing logic.Additionally, add an optional
content_typefield toObjectMeta. Most backends already send the content type anyways, so populating it should be quite limited in cost, and no explicit different client config should be necessary.Describe alternatives you've considered
Using custom metadata, as introduced in apache/arrow-rs#4999. This however is distinct from content-type and requires an additional request for some backends (AWS), while content-type is sent inline alongside the data.