vinted / elasticsearch-dsl-rs

Strongly typed Elasticsearch DSL written in Rust
Apache License 2.0
197 stars 18 forks source link

Add Deserialize #212

Open fulmicoton opened 1 year ago

fulmicoton commented 1 year ago

The QueryDSL makes it possible to serialize the query. Would it be ok to add the Deserialize implementation?

buinauskas commented 1 year ago

@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.

oknozor commented 9 months ago

I might need that soon and send a PR if I find enough time to do it. I am storing some query filters in a file and currently I need to do these kind of shenanigans to retrieve those:

        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.

buinauskas commented 9 months ago

@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.

pjankiewicz commented 3 months ago

+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 #[serde(untagged)] and one without. The ones without could be use for serialization and deserialization and the other for queries. Having those 2 data structures with an easy way to convert one from the other could be a solution.

pjankiewicz commented 3 months ago

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>
    }
}
buinauskas commented 2 months ago

Hi, sorry for a late reply.

I think the problem is mostly that the serialization is used to create a query and not to represent the object.

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 :/