a `json.RawMessage` search response's hit fields
Previous I'm using a es client to search.
This es client has a feature that it's search response's hit field has s Source field with json.RawMessage field, contain the raw bytes from API.
And so I can unmarshal it to the struct I'm expecting.
It's SDK api look like this:
result, err := es.search(...)
if err != nil {
return errgo.Wrap(err, "search")
}
for i, hit := range result.Hits.Hits {
var source = Subject{}
// and hit.Source is a json.RawMesssage, So I can unmarshal it here.
err = json.Unmarshal(hit.Source, &source)
if err != nil {
return err
}
(it's source https://github.com/olivere/elastic/blob/e5be2e003d85f8b9bf2c97662e34c6a857f60a61/search.go#L779)
But, currently, meilisearch's SearchResponse.Hits is a []interface{}, so I'll need to do many type case or marshal to json bytes then unmarshal to back.
Hope there could be some API improvement on this.
Or I hope it's possible I can get the raw response bytes somehow so I can unmarshal from the response directly.
Hi @Trim21, Yes, this could be a very good addition to this repo 🚀 ! For the moment it is not in our priorities unfortunately to modify this repo because others are not yet updated with the last release. Thanks for your suggestion ❤️
@alallema , can I work on this issue? Where to start with for this issue in the source code?
this is a really useful feature, and current API return type is really pain in the ass.
Even only add a new field in response containing the raw bytes of http body is enough to resolve this.
Hi @26tanishabanik, Thanks for proposing, like @trim21 you can:
- add a new field in the
SearchResponseresponse structure that contains the raw response - create a new method called
SearchRaw()which is exactly the same as theSearch()method but instead of returning aSearchResponseit returns the raw response.
I prefer the second method but if you have trouble with it, you can choose the first option.
Hi @26tanishabanik are you still interested in working this issue? otherwise I can take a look
Hi @ginglis13, No one seems to work on this issue right now. We prefer not assigning people to our issues because sometimes people ask to be assigned and never come back, which discourages volunteer contributors to open a PR to fix this issue. We will accept and merge the first PR that fixes correctly and well implements the issue following our contributing guidelines. We are looking forward to reviewing your PR.
Any release plan?