alamb commented on code in PR #548:
URL:
https://github.com/apache/arrow-rs-object-store/pull/548#discussion_r2550140973
##########
src/lib.rs:
##########
@@ -1756,6 +1761,73 @@ pub struct PutResult {
pub version: Option<String>,
}
+/// Configure preconditions for the copy operation
+#[derive(Debug, Clone, Copy, PartialEq, Eq, Default)]
+pub enum CopyMode {
+ /// Perform an atomic write operation, overwriting any object present at
the provided path
+ #[default]
+ Overwrite,
+ /// Perform an atomic write operation, returning [`Error::AlreadyExists`]
if an
+ /// object already exists at the provided path
+ Create,
+}
+
+/// Options for a copy request
+#[derive(Debug, Clone, Default)]
+pub struct CopyOptions {
+ /// Configure the [`CopyMode`] for this operation
+ pub mode: CopyMode,
Review Comment:
> TBH I don't see what's the reason for avoiding breaking changes, it's a
0.x crate after all. And it's the question of "how much breaking" it is. We're
not re-designing the entire interface for that again.
One rationale is to speed up the adoption downstream -- since object_store
is "low" in the dependency stack, if we make a breaking change to the API, we
then need to wait for that breaking change releases in all other downstream
dependencies
So for example, it can take up to 4 months to get into datafusion (wait 3
months for next major arrow release and then a month for the next major
datafusion release)
That timeframe is not a deal breaker nor does it mean we shouldn't make
breaking changes ever, but I do think it is worth considering as we design APIs
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
