expose the sql AST ( + shape definition) to schema config functions

[bradzacher]

We're looking to do some stuff involving allowing query arguments on deeply nested data.

The current solution is as follows:

1. only allow the deeply nested args on non-batched joins
2. on a resolver's arguments definition, also add a "request path" which is the required
3. before passing the GQL AST to JM, we scan it to determine if the required properties are selected, and we manually add them to the AST if they are not.

• at the same time we count the number of times the property's name is referenced, and create the alias as per https://github.com/stems/join-monster/blob/7005cd1963ec9a5e1ba6bd92f730573876ba1fed/src/alias-namespace.js#L43-L48. (we're relying on the fact that the SQL gets generated depth-first in the query order).

4. finally we save this alias on the context so that it can be accessed within the required where function call (we only define arguments on the base resolvers, so we're relying on the fact that there's no parallelism, so that the context doesn't get mismatched between each root resolver).
5. in the where function, pull the required alias out of the context for the specific query arg.
6. finally, after JM has generated the SQL, in the DBCallback we remove any manually added nodes from the GQL AST (GQL will then scrub any data not specified in the AST before returning the payload).

This solution works well, and allows transparent querying of join fields without forcing the consumer to select data that they don't need.

Now ideally, we'd love to be able to remove step 4, and in step 5 instead use the alias pulled directly from the SQL AST, but from what I can see - it's kept entirely internal to JM.

It'd be great if it could be passed in some way to the userland config functions (such as where/orderby), so that users can use that information for advanced querying.

alternately if you don't want to expose JM's internals that deeply, it'd be good if JM sent through/exposed an object with the mapping of field names to aliases (maybe as a nested object).