chore | adding the support for querying multi interaction filters #203
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #203 +/- ##
============================================
- Coverage 21.84% 21.39% -0.46%
Complexity 75 75
============================================
Files 70 70
Lines 1831 1856 +25
Branches 55 55
============================================
- Hits 400 397 -3
- Misses 1422 1450 +28
Partials 9 9
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
...e-graphql-entity-schema/src/main/java/org/hypertrace/graphql/entity/dao/EntityDaoModule.java
Outdated
Show resolved
Hide resolved
...ql-entity-schema/src/main/java/org/hypertrace/graphql/entity/request/EdgeRequestBuilder.java
Outdated
Show resolved
Hide resolved
...in/java/org/hypertrace/graphql/entity/dao/GatewayServiceEntityInteractionRequestBuilder.java
Outdated
Show resolved
Hide resolved
...in/java/org/hypertrace/graphql/entity/dao/GatewayServiceEntityInteractionRequestBuilder.java
Show resolved
Hide resolved
...ql-entity-schema/src/main/java/org/hypertrace/graphql/entity/request/EdgeRequestBuilder.java
Outdated
Show resolved
Hide resolved
| private Single<Map<String, EdgeSetRequest>> getEdgeSetRequest( | ||
| GraphQlRequestContext context, | ||
| EdgeType edgeType, | ||
| Map<String, Set<SelectedField>> edgeFields) { |
There was a problem hiding this comment.
in general, be careful with the naming especial with fields since they can represent any part of the query. These, if I'm following correctly represent a map of entity types to a set of edge set fields (e.g. outgoingEdges( neighborScope: "SERVICE") would be one entry under the service key) rather than the fields that define an actual edge.
I missed this earlier but since we group at the level of edge scope + edge type (e.g. outgoing services), that means if I had two edge sets of the same type with different filters, the filters would be ANDed. Is that desirable? If yes, can leave. If no, you'd want to avoid the grouping by type and create a new EdgeSetRequest for every edge set field and hold them as a collection rather than mapped by entity type.
There was a problem hiding this comment.
I don't see any use case for having different filters for the same set of edges. We had the same issue when we built the use case of a third-party application flow and decided to make the filters as AND across all edges defined. I think we can leave like this.
There was a problem hiding this comment.
renamed other arguments to be more meaningful
There was a problem hiding this comment.
I don't see any use case for having different filters for the same set of edges.
Disagree - there's plenty of compelling use cases here. I want to get a set of by slow downstream services and a set of my high error rate downstream services, for example. It's not just about AND/OR - it's what the caller wants to separate e.g. downstream external APIs vs downstream internal APIs.
There was a problem hiding this comment.
I think we might eventually want to change this, but can defer until we have a need.
...ql-entity-schema/src/main/java/org/hypertrace/graphql/entity/request/EdgeRequestBuilder.java
Outdated
Show resolved
Hide resolved
...in/java/org/hypertrace/graphql/entity/dao/GatewayServiceEntityInteractionRequestBuilder.java
Show resolved
Hide resolved
...l-entity-schema/src/main/java/org/hypertrace/graphql/entity/request/EdgeSetGroupRequest.java
Outdated
Show resolved
Hide resolved
...-schema/src/main/java/org/hypertrace/graphql/entity/dao/GatewayServiceEntityEdgeFetcher.java
Outdated
Show resolved
Hide resolved
No description provided.