Skip to content

feat: impl PartialEq + Eq for GetOptions & PutPayload #7152

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion object_store/src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -916,7 +916,7 @@ pub struct ObjectMeta {
}

/// Options for a get request, such as range
#[derive(Debug, Default, Clone)]
#[derive(Debug, Default, Clone, PartialEq, Eq)]
pub struct GetOptions {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this work if we add a dyn Any context/extensions field as being discussed in #7135

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we require extensions to implement not only Any but also Eq and PartialEq w/ their own type? That would require some additional bookkeeping code withing AnyMap to store the vtable entries though, or don't use Any at all but trait Extension: Eq + std::fmt::Debug or something like that. The more I think about it, the more convinced I am that a proper new trait would be better.

Copy link

@waynr waynr Feb 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eq and PartialEq aren't dyn-compatible because they take Self as a type parameter: https://doc.rust-lang.org/error_codes/E0038.html#trait-uses-self-as-a-type-parameter-in-the-supertrait-listing

We could work around that with custom PartialEq and Eq implementations that ignore the extensions field discussed in https://github.com/apache/arrow-rs/issues/7155 (opened in favor of #7135). Given that the extensions are meant to be used by custom ObjectStore implementations/wrappers and ignored by the builtin backends this shouldn't be a problem, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it's not dyn-safe, but you still can implement this via a trait and the right signature, see #7160 (comment)

/// Request will succeed if the `ObjectMeta::e_tag` matches
/// otherwise returning [`Error::Precondition`]
Expand Down
2 changes: 1 addition & 1 deletion object_store/src/payload.rs
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ use bytes::Bytes;
use std::sync::Arc;

/// A cheaply cloneable, ordered collection of [`Bytes`]
#[derive(Debug, Clone)]
#[derive(Debug, Clone, PartialEq, Eq)]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if people might expect this to be agnostic to chunking?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. I think NOT equalizing chunking might be the more correct Eq implementation, because if you want to test optimizations / implementation details, this is important. I think we should document it though.

pub struct PutPayload(Arc<[Bytes]>);

impl Default for PutPayload {
Expand Down
Loading