-
Notifications
You must be signed in to change notification settings - Fork 18
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
Add Deserialize #212
Comments
@fulmicoton Hello, sorry for the late response, my notifications must've been broken as I didn't see this issue. It would definitely be OK to add them, I never had the capacity to do so. |
I might need that soon and send a PR if I find enough time to do it. for category in geo_query.category {
let category = tagger::CATEGORIES.get(category).expect("category should exist");
for filter in &category.filter {
match filter {
Filter::Term(term) => {
for (field, value) in term {
query = query.filter(Query::term(field, &value.value));
}
}
Filter::Terms(terms) => {
for (field, values) in terms {
query = query.filter(Query::terms(field, values));
}
}
}
}
} Being able to deserialize this directly would be neat. |
@oknozor it definitely would, it's just that I have very little capacity for this and Elasticsearch supports a wild set of ways to deserialize the JSON into the query. I'll try looking into that though. |
+1 it would be definitely helpful for me too. I think the problem is mostly that the serialization is used to create a query and not to represent the object. The most elegant way that I can think of would be to somehow define 2 companion types one would be used for constructing queries with |
I went into a deeper rabbit whole. I found this crate - https://lib.rs/crates/serde-split. It would allow us to use untagged serialization only with JSON format and other formats would be tagged if you need to serialize/deserialize them. #[derive(Deserialize, Serialize)]
#[json(untagged)]
pub enum ObjectPosition {
Static(Vec2),
Path {
start: Vec2,
points: Vec<Vec2>
}
} |
Hi, sorry for a late reply.
this is mostly true because the primary goal of the lib was to allow type-safe elasticsearch query builder to enable me and the team I'm working with to build correct queries and I did not intend that I'll need to deserialize them. Ideally, I would probably need to separate the logic out the way this has been done in official clients where they have a structure that represents the query with all the deserialization options and one way to serialize them, additionally they have separate query builder on top of this. The problem I'm facing is that I barely have any capacity to work on this because I'm out of breath with current work :/ |
The QueryDSL makes it possible to serialize the query. Would it be ok to add the Deserialize implementation?
The text was updated successfully, but these errors were encountered: