Make the object_type_name available in async_graphql::context::SelectionField

[lastmjs]

Currently async_graphql::context::SelectionField will give you access to the field name, alias, arguments, and child fields through the selection_set. This all works very well, and I am able to return arbitrarily complex selection sets for my project Sudograph. Sudograph is a GraphQL database for the Internet Computer, it is designed in a particular way probably not common to how GraphQL is normally used with traditional databases like Postgres/MySQL/MongoDB. I just bring this up in case you're questioning why I need this functionality.

I am missing a key part of the selection set, which is the object type from the schema that the current selection set or field belongs to. I need this information to implement searching/filtering on relations within a selection set, and without it being available to me in async_graphql::context::SelectionField I believe I am going to have to get the SDL from the schema, parse it into an AST, and manually walk it to find the object types that I need. I think this will work fine, but it will be a lot of extra work and processing when a simple object_type_name method available on async_graphql::context::SelectionField would save me all of that trouble.

[lastmjs]

And to explain a little bit more my use case, Sudograph is basically taking the entire query, parsing it into a set of structs that another project Sudodb takes to resolve against Internet Computer data structures. I am not using resolvers to actually resolve relations, Sudodb is doing that, and thus I need to parse out of the query everything necessary to perform the operations before the resolvers resolve. Sudodb returns a JSON string with the entire result, and the resolvers simply grab the fields from the deserialized JSON string.

[sunli829]

The signature of this function is SelectionField::object_type_name(&self) -> Option<&str>. If the type of this field is not an Object, it will return None. What do you think?

[lastmjs]

I want to know the object_type_name of the object type that the field belongs to, so it should always have an object_type_name

[lastmjs]

Having a separate type_name which would be the type of that field would be interesting too, I think that would be useful as well

[lastmjs]

You know what, I'm sorry, I do think that object_type_name and type_name would be nice to have, but I believe I was actually confused on how to achieve my use case. I actually need this type of information in the pub fn arguments(&self) -> ServerResult<Vec<(Name, Value)>> so that I can properly filter/search when resolving everything from Sudodb...having the object_type_name and type_name on a selection_field will not necessarily help me there, I will need to do an AST traversal no matter what it seems. It's within the arguments that I need to know if a field type is an object type or not, and the format is specific to my project, I don't think it can be easily generalized.

Though I think a case can be made for having the extra object_type_name and type_name anyway.

[sunli829]

After I added the object_type_name and type_name functions, can it solve the problem?

[lastmjs]

Adding those functions will not solve my problem, I have already solved my problem with an AST traversal of inputs from the arguments...I was trying to explain that here: #546 (comment)

So, I think it would be nice to have those two functions, but they don't solve my use case, sorry for the confusion :)

[sunli829]

Okay, these two functions will reduce query performance, so I won't add them. I will close this issue now. If you have any questions, please feel free to open it. 😁