`@Propagate` feature. Allow passing input from query to source

[phillip-kruger]

At the moment this can be done by inspecting the @Context - however, it would be nice to indicate a Source methods that some of the parameters can be passed from the original query.

This can then maybe be added as an Optional parameter in the schema, so the client can still override it.

example:

@Query
public List<Member> getMembers(String club){
//...
}

public List<MembershipType> getMemberships(@Propagate String club, Source Member member){
// ...
}

[phillip-kruger]

@t1 @andymc12 @jmartisk w.d.y.t of the above idea ?

[t1]

Sounds good (but it's not very high on my list of priorities ;-) I suppose there are some details that would have to be specified; e.g. what happens, if there are multiple queries that (directly or indirectly) return Members, but don't have a club parameter?

And I think that propagated parameters should be kept separate from normal parameters: it may not make sense to get the Members of one club but their MembershipTypes for another. The service should be able to control that.

And one more thought: maybe less is more and we should stick to using the @Context for such use-cases... maybe.

[jmartisk]

TBH this sounds like a bit too much of "magic" to me, and there will be edge cases where this will become confusing or hard to implement reasonably. Like @t1 pointed out, multiple queries returning Members but having different parameters. It will also become hard to read the code and mentally connect the @Propagate argument with the original Query argument, I think (unless IDEs receive tooling to support this).

[phillip-kruger]

So the idea is as follows, since we build the schema anyway, and know all the queries that use a certain source method, we do the following: if the root query contains that param (the propagated one) we add it as an optional (by default) to the source method query. We add a param to the @Propagate annotation that allow you to not do that , so @Propagate(allowOverride=false) to not make the param optional (i.e always get it from the root). For root queries that does not have this param, it gets added to the sub (source) query as per usual.

I agree that it's not high on the priority list, I just came across the issue, and wanted to discuss...

[t1]

I agree with Jan that this might not be worth its mental weight.