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

Add Deserialize #212

Open
fulmicoton opened this issue Mar 17, 2023 · 6 comments
Open

Add Deserialize #212

fulmicoton opened this issue Mar 17, 2023 · 6 comments

Comments

@fulmicoton
Copy link
Contributor

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

@buinauskas
Copy link
Collaborator

@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
Copy link
Contributor

oknozor commented Nov 13, 2023

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
Copy link
Collaborator

@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
Copy link

+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
Copy link

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
Copy link
Collaborator

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

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

No branches or pull requests

4 participants