Skip to content
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

Display 0 bytesRead in search responses #1788

Merged
merged 1 commit into from
Feb 21, 2023

Conversation

metonymic-smokey
Copy link
Member

Currently, when firing multiple queries with "score" : "none", the first query response displays the non-zero bytesRead as part of the JSON response. Subsequent queries do not display it as part of the response since the bytesRead is 0.
This PR fixes it such that even if the bytesRead is 0, it displays it as part of the response.

@abhinavdangeti
Copy link
Member

@metonymic-smokey and why is the bytesRead 0 when "score":"none" and non-zero only in the first response?

Copy link
Contributor

@iamrajiv iamrajiv left a comment

Choose a reason for hiding this comment

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

While it is true that removing the omitemptyoption from the json tag of the BytesRead
field would ensure that the field is included in the JSON response, even if it's zero, using a MarshalJSONfunction like this is a good practice. This function creates an Alias type with the same field names and types as the original SearchResult
struct, and marshals a new anonymous struct that includes a pointer to the Alias object. This way, you can customize the way the JSON output is generated, such as including or omitting certain fields or modifying their values. Maybe we can have custom MarshalJSON functions in utility packages that we can use in our code.

func (sr *SearchResult) MarshalJSON() ([]byte, error) {
    type Alias SearchResult
    return json.Marshal(&struct {
        *Alias
        BytesRead uint64 `json:"bytesRead,omitempty"`
    }{
        Alias:     (*Alias)(sr),
        BytesRead: sr.BytesRead,
    })
}

@metonymic-smokey
Copy link
Member Author

@metonymic-smokey and why is the bytesRead 0 when "score":"none" and non-zero only in the first response?

Regarding queries where score is "none":
If the segment in a snapshot is already mmaped, bytes read will not be incremented for it. Since it is mmaped for the first query(and not for subsequent queries), bytesRead is incremented only for the first query.
Also, in the postings list iterator() function, since includeFreqNorm and includeLocs are false, bytesRead will not be incremented there either.

This behaviour is on expected lines, as far as I remember. Thanks!

@metonymic-smokey
Copy link
Member Author

While it is true that removing the omitemptyoption from the json tag of the BytesRead field would ensure that the field is included in the JSON response, even if it's zero, using a MarshalJSONfunction like this is a good practice. This function creates an Alias type with the same field names and types as the original SearchResult struct, and marshals a new anonymous struct that includes a pointer to the Alias object. This way, you can customize the way the JSON output is generated, such as including or omitting certain fields or modifying their values. Maybe we can have custom MarshalJSON functions in utility packages that we can use in our code.

func (sr *SearchResult) MarshalJSON() ([]byte, error) {
    type Alias SearchResult
    return json.Marshal(&struct {
        *Alias
        BytesRead uint64 `json:"bytesRead,omitempty"`
    }{
        Alias:     (*Alias)(sr),
        BytesRead: sr.BytesRead,
    })
}

@iamrajiv thanks for the suggestion, but I don't think this requires custom JSON marshalling/unmarshalling.

@abhinavdangeti abhinavdangeti added this to the v2.3.7 milestone Feb 21, 2023
@abhinavdangeti abhinavdangeti merged commit a8beab1 into blevesearch:master Feb 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants