Open aawsome opened 7 months ago
Hi, @aawsome, thank you for bringing up the issue. I've been considering this for some time but haven't found a way to integrate this feature into OpenDAL.
Here are my concerns:
Modifying object states seems more akin to control plane operations rather than data plane activities. Perhaps users have better methods of managing those objects through Jobs and lifecycles?
This feature is too specific to S3, making it challenging to design consistently across different services.
The change_state
API overlaps with COPY
.
Using op.change_state("hello.txt", "STANDARD")?.await
achieves the same result as op.copy("hello.txt")
with the default storage class STANDARD
.
Introducing this API would make our public API reveal the storage class, preventing writing uniform code across services.
Could we consider a restore
API?
let res = op.restore("archived.tar.zst").await?;
We need to conduct further research by exploring s3
, gcs
, azblob
, and comparing the similarities and differences between these services.
Opendal already supports specifying storage classes, e.g. for AWS S3:
Now, sometimes you want or need to change the storage class. In this example, before being able to access the data in AWS Glacier Deep Archive, you need to warm-up the data by requesting to change the storage class to "STANDARD".
It would be very nice if the opendal service directly supports this kind of storage class change, e.g. something like
There are some cases to consider:
As a reference, where such things are useful, see https://github.com/rustic-rs/rustic/discussions/692.