quickwit-oss / quickwit-oss/quickwit
[refactoring] Find a solution to avoid deserializing the query_ast over and over
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 11.7k
- Forks
- 597
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 37
Description
Right now, for convenience, we directly use the search request proto object as our model for the search request.
The query ast is serialized as JSON in it.
We end up deserializing/modify/reserializing it a lot during search.
It would be nice to do some refactoring to avoid this.
e.g.
#[derive(Clone)]
pub struct SearchRequest {
pub query_ast: Arc<QueryAst>,
search_request_proto: SearchRequestProto
}
impl TryFrom<SearchRequestProto> for SearchRequest {
type Error = anyhow::Error;
fn try_from(search_request_proto: SearchRequestProto) -> Result<Self, Self::Error> {
let query_ast: Arc<QueryAst> = serde_json::from_str::<QueryAst>(&search_request_proto.query_ast)
.context("invalid query ast")?
.into();
Ok(SearchRequest {
query_ast,
search_request_proto,
})
}
}
impl Deref for SearchRequest {
type Target = SearchRequestProto;
fn deref(&self) -> &SearchRequestProto {
&self.search_request_proto
}
}
impl DerefMut for SearchRequest {
fn deref_mut(&mut self) -> &mut SearchRequestProto {
&mut self.search_request_proto
}
}
or pushing the JSON serialization / deserialization of the QueryAST into the message using a custom message implementation. (We need to make sure to make it an Arc to make sure a copy of the AST is not too heavy)
or using a different model object for the search request
or breaking the search request into several different models.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing how SearchRequestProto, QueryAst, and the search request are created and mutated during search. Compare the proposed wrapper, custom message serialization, separate model, and split-model options; done means the chosen design avoids repeated QueryAst serialization while preserving request behavior and safe shared ownership.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend, search
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100