-
Notifications
You must be signed in to change notification settings - Fork 102
use an OffsetDateTime on the ClientStats #244
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
Conversation
pub database_size: usize, | ||
pub last_update: Option<String>, | ||
#[serde(with = "time::serde::rfc3339::option")] | ||
pub last_update: Option<OffsetDateTime>, |
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.
Should I be worried because no tests were changed and, we still have the CI passing? 😅
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 totally get your concern ahah!
We actually have only one test on this route:
use meilisearch_sdk::{client::*, indexes::*};
futures::executor::block_on(async move {
let client = Client::new("http://localhost:7700", "masterKey");
let stats = client.get_stats().await.unwrap();
});
And the unwrap
right there ensure we were able to parse the new date format: client.get_stats().await.unwrap();
On another note I'm wondering if we could add more tests though, but we can't test a lot of things because we don't know what the database_size
is supposed to be, we don't really know the time of the last_update
or what indexes are in the Client
currently 🤔
pub struct ClientStats {
pub database_size: usize,
pub last_update: Option<String>,
pub indexes: HashMap<String, IndexStats>,
}
One test we could add though would be to create an index and ensure we find it later in the stats + ensure the time of the last_update
>= the time we sent our update but that feel like testing meilisearch more than meilisearch-rust, 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 totally agree with that idea! Or maybe if it is possible you could create a mock of the API response, adding a specific value in the database_size
and last_update
it will make it easier to test after that. But of course, this mock need only is used in the raw response of the API, to ensure the crate will be able to parse it accordingly.
I think this way you could have the whole TDD flow :)
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.
Creating a mock would be the best thing, but I don't have the time currently, sadly 😒
We could open an issue, though, I think faux would be really suited for this library 👍
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.
🔥 🔥
bors merge |
Build succeeded: |
272: Update version for the next release (v0.16.0) r=brunoocasali a=brunoocasali ### Release notes: ##⚠️ Breaking changes * Use an `OffsetDateTime` on the `ClientStats` (#244) `@irevoire` * Fixed formatting with clippy & Removed `Document` trait (#267) `@irevoire` ## 🚀 Enhancements * Add methods to automatically add/update documents in batches (#262) `@abhizer` * Feature/Tenant Token (#263, #264) `@brunoocasali` ## Misc * Create an example showing how to update the Settings (#245) `@irevoire` Thanks again to `@abhizer,` `@bidoubiwa,` `@brunoocasali,` `@irevoire,` and Adrian Coutsoftides! 🎉 Co-authored-by: Bruno Casali <[email protected]>
Pull Request
What does this PR do?
I noticed we were still deserializing the
last_update
in theClientStats
structure in anOption<String>
.I typed the
String
into anOffsetDateTime
.PR checklist
Please check if your PR fulfills the following requirements:
Thank you so much for contributing to Meilisearch!
I also found a "bug" in one of our doctest where we were creating an index with a bad name.