Skip to content
This repository was archived by the owner on Apr 14, 2022. It is now read-only.

Support filtering inside a Map #263

Closed
Totktonada opened this issue Feb 1, 2019 · 3 comments
Closed

Support filtering inside a Map #263

Totktonada opened this issue Feb 1, 2019 · 3 comments
Labels
archived enhancement New feature or request wontfix This will not be worked on

Comments

@Totktonada
Copy link
Member

Totktonada commented Feb 1, 2019

GraphQL does not support the Map type natively: it defines an JSON Object with arbitrary string keys and values of certain type. So avro-schema map type is mapped into a Scalar in our implementation. OTOH, GraphQL allows to pass an argument to any field (including scalars, AFAIU). So we can add an argument(s) that will instruct the library to postprocess a map.

Using the lua-jsonpath library seems to be quite general solution, but it has one disadvantage: we cannot guarantee that a jsonpath expression will not change a shape of a query result. If we change the shape the result will not more fit an original avro-schema. So we need some more specific solution.

We can just list all fields that are need to be shown in a result:

{
    my_collection {
        my_map(fields: ["foo", "bar"])
    }
}
@Totktonada Totktonada added enhancement New feature or request customer labels Feb 1, 2019
@Totktonada
Copy link
Member Author

Totktonada commented Feb 1, 2019

From the other side, aliases already breaks this property: the result is not more guaranteed to match an original avro-schema. Maybe shape of a result should be more or less up to a user. So we can consider jsonpath if it allows to filter inner fields w/o moving then on the upper level. But it seems it don't.

@Totktonada
Copy link
Member Author

From the other side, aliases already breaks this property: the result is not more guaranteed to match an original avro-schema.

This can be fixed, filed #269 for this.

@Totktonada Totktonada added wontfix This will not be worked on archived labels Apr 13, 2022
@Totktonada
Copy link
Member Author

I'm going to archive the repository. I'll proceed as follows:

  • Mark all open pull requests with the archived label and close.
  • Mark all open issues with archived and wontfix labels and close.
  • Archive the repository.

Consider the following projects:

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
archived enhancement New feature or request wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant