You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue should be the central place for discussion on federated interfaces.
Atm, I don't think there's a meaningful way to interpret two interfaces with conflicting definitions. The merger responds with an error when this is encountered.
If the definitions are the same, the merger allows for interfaces to show up in different services but the planner does not handle them very well. If there was an interface that spanned two services, the gateway will currently create a planner that always fire both queries regardless of wether the id belongs to the target service. Ideally, the planner could mark a step as optional depending on some predicate and not execute a step if it doesn't apply at query time.
This issue should be the central place for discussion on federated interfaces.
Atm, I don't think there's a meaningful way to interpret two interfaces with conflicting definitions. The merger responds with an error when this is encountered.
If the definitions are the same, the merger allows for interfaces to show up in different services but the planner does not handle them very well. If there was an interface that spanned two services, the gateway will currently create a planner that always fire both queries regardless of wether the
id
belongs to the target service. Ideally, the planner could mark a step as optional depending on some predicate and not execute a step if it doesn't apply at query time.Related to #43
The text was updated successfully, but these errors were encountered: