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
Nested fields #2298
Nested fields #2298
Conversation
// then we need to convert the `serde_json::Map` into an `IndexMap`. | ||
let document = document.into_iter().collect(); |
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'm wondering, is there a risk that the fields in the Map are reordered, and returned in a different order than the original document?
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.
Yes, I was concerned about that too. From what I see it works but it's not specified it should so I guess I'm just lucky.
I would like to move the permissive-json-pointer
crate into meilisearch so we could make it work directly with the IndexMap
.
Do you think this needs to be fixed before the RC0 or can it wait until the RC1?
@gmourier @curquiza
Basically, the jsons in hits
could have their fields in a different order each time.
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.
actually, when the preserve_order
feature from serde_json is enables, a serde_json::Map
is nothing but an IndexMap
under the hood: https://docs.serde.rs/src/serde_json/map.rs.html#23-26
and it turns out that we're lucky: https://github.com/meilisearch/meilisearch/blob/main/meilisearch-lib/Cargo.toml#L45
This now begs the question: Do we need to do the back and forth conversion?
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! No we don't, and I guess we could just remove entirely the IndexMap
and define a Document
as a serde_json::Map<String, Value>
!
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 can indeed 🤔
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.
Basically, the jsons in hits could have their fields in a different order each time.
Ok to wait for rc1 to fix this!
7e45f8a
to
68da743
Compare
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 to me. We can now wait for the users to try to break this feature! I am also awaiting the benchmarks too.
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 to me. Are we waiting for meilisearch/milli#458 to be merged and released?
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.
Thank you for the clippy fix!
Yep we need to wait for the release because we need to publish the new |
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 to me, thank you @irevoire!
bors merge |
2298: Nested fields r=irevoire a=irevoire There are a few things that I want to fix _AFTER_ merging this PR. For the following RCs. ## Stop the useless conversion In the `search.rs` I convert a `Document` to a `Value`, and then the `Value` to a `Document` and then back to a `Value` etc. I should stop doing all these conversion and stick to one format. Probably by merging my `permissive-json-pointer` crate into meilisearch. That would also give me the opportunity to work directly with obkvs and stops deserializing fields I don't need. ## Add more test specific to the nested Everything seems to works but I should write tests to double check that the nested works well with the `formatted` field. ## See how I could stop iterating on hashmap and instead fill them correctly This is related to milli. I really often needs to iterate over hashmap to see if a field is a subset of another field. I could probably generate a structure containing all the possible key values. ie. the user say `doggo` is an attribute to retrieve. Instead of iterating on all the attributes to retrieve to check if `doggo.name` is a subset of `doggo`. I should insert `doggo.name` in the attributes to retrieve map. Co-authored-by: Tamo <tamo@meilisearch.com>
Build failed: |
Is it a bug in Clippy? |
yeah look like, it says it's an internal compiler error 😒 Also the benchmarks just finished running and it's worse than I thought 😩
I don't really understand how the geosearch can be so slow |
bors merge |
2313: fix(search): remove the back and forth between the IndexMap and the serde_json::Map r=irevoire a=irevoire This is ok because we're using the preserve_order feature in serde_json which is already internally using an IndexMap. See #2298 (comment) Co-authored-by: Tamo <tamo@meilisearch.com>
There are a few things that I want to fix AFTER merging this PR.
For the following RCs.
Stop the useless conversion
In the
search.rs
I convert aDocument
to aValue
, and then theValue
to aDocument
and then back to aValue
etc. I should stop doing all these conversion and stick to one format.Probably by merging my
permissive-json-pointer
crate into meilisearch.That would also give me the opportunity to work directly with obkvs and stops deserializing fields I don't need.
Add more test specific to the nested
Everything seems to works but I should write tests to double check that the nested works well with the
formatted
field.See how I could stop iterating on hashmap and instead fill them correctly
This is related to milli. I really often needs to iterate over hashmap to see if a field is a subset of another field. I could probably generate a structure containing all the possible key values.
ie. the user say
doggo
is an attribute to retrieve. Instead of iterating on all the attributes to retrieve to check ifdoggo.name
is a subset ofdoggo
. I should insertdoggo.name
in the attributes to retrieve map.