-
Notifications
You must be signed in to change notification settings - Fork 169
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
RUST-1392 Add GridFS support: Implement public API with placeholder code #688
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking good! i'm also going to work on adding some design comments for the other reviewers once we tag them in
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking good! a few more style/design comments.
src/gridfs.rs
Outdated
} | ||
|
||
/// Finds and returns the files collection documents that match the filter. | ||
pub fn find<T>(&self, filter: Document, options: GridFsBucketOptions) -> Result<Cursor<T>> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because we know the exact schema of the documents that will be returned by this find operation, it might be more useful to users to add the FilesCollectionDocument
type to the public API and return a <Result<Cursor<FilesCollectionDocument>>
here. While we do use generic types for most of our find-related methods, I'm not sure how useful that would actually be here given that there isn't any flexibility in what's returned. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking it might make sense to get rid of the FilesCollectionDocument
struct altogether? We could just return a cursor over bson::Document
s that way. The only reason I can think of to keep the struct is for code completion and discovery purposes, since accessing the fields of the document can be achieved through the bson::Document
API anyway. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The nice thing about using the FilesCollectionDocument
struct rather than a plain Document
is that the validation of the data returned is done ahead of time by the cursor, so a user wanting to inspect a field just needs to access it on the struct. With a Document
, a user wanting to inspect the length
field would need to do something like:
doc.get_i64("length").unwrap();
which requires knowing what the type of that field should be. Even though the unwrap should never fail it's nice to have the guarantee of the type system rather than needing to assume an invariant/write extra error handling.
That said, I'd be interested in what other members of the team think about using a defined struct here; we can leave this thread open for their input once I tag them in for review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the suggestion to have a FilesCollectionDocument
type, for the reasons Isabel mentioned; it's a well-defined format and when possible we generally try to model those types
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking good! just one more comment
src/db/mod.rs
Outdated
) -> GridFsBucket { | ||
GridFsBucket { | ||
db: self.clone(), | ||
options: options.into(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be useful to store the options that get inherited from the parent database directly in the options structs here. We currently do this in some of our other structs, e.g. Collection::new()
. That way we won't get possibly conflicting values when calling, for example, the read_concern()
method vs. inspecting the read_concern
field directly on the options.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be a good idea to include to store the fields specified in the GridFsBucketOptions
struct directly within GridFsBucket
, especially since chunk_size_bytes
and bucket_name
are used frequently in the upload and download methods and it makes the code harder to read to figure out those values from all the layers of Option
around those fields.
src/gridfs.rs
Outdated
|
||
/// Downloads the contents of the stored file specified by `id` and writes | ||
/// the contents to the destination [`GridFsDownloadStream`]. Uses the `futures` crate. | ||
pub async fn download_to_stream_futures( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As ugly as it is, I think we may need to specify futures_0_3
here, since if an 0.4 or 1.0 version of that crate is released, we'll still need to maintain this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good! just various nits around the types used
Cargo.toml
Outdated
@@ -59,6 +59,7 @@ bson = { git = "https://github.com/mongodb/bson-rust", branch = "main" } | |||
chrono = "0.4.7" | |||
derivative = "2.1.1" | |||
flate2 = { version = "1.0", optional = true } | |||
futures = "0.3.14" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we don't need to explicitly pull in futures-core
, -util
, or -executor
if we're using futures
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could do away with those but that would require changing every import of futures-core
, -util
and -executor
in the driver. Is that something we want to do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The various individual futures-x
crates have differing stability guarantees, which is why we depend on them directly. See this comment for more context / reasoning.
Given that, I think we'll want to continue to depend on the various subcrates directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I see, that makes sense. Fixed!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
caefc84
to
01238f5
Compare
WIP: Adding GridFS support to the Rust Driver.