feat(schema-attribute-info)
Depends on schema-retrieval MR: listens to statistics for schema attributes
Merge request reports
Activity
requested review from @milho001
assigned to @s.a.vink
added 4 commits
-
968d187d...fa0e64ae - 3 commits from branch
main
- d6df5262 - feat(schema-attribute-info): statistics for schema attributes
-
968d187d...fa0e64ae - 3 commits from branch
68 attributeStats: Array<AttributeStats>; 69 }; 70 71 export type AttributeStats = 72 | BooleanAttributeStats 73 | StringAttributeStats 74 | NumberAttributeStats 75 | DateTimeAttributeStats 76 | LocationAttributeStats; 77 78 export type CommonAttributeStats = { 79 name: string; 80 type: string; 81 }; 82 83 export type BooleanAttributeStats = CommonAttributeStats & { 72 80 73 81 return graph; 74 82 } 83 84 public static addAttributeInfoToGraph(graph: SchemaGraph, graphStats: GraphAttributeStats): SchemaGraph { 85 const { nodeStats, edgeStats } = graphStats; 86 87 graph.nodes.forEach((node) => { 88 const nodeStat = nodeStats.find((stat) => stat.key === node.key); In principle it looks good to me, I have a few comments but nothing major.
I can however not currently test out the PR myself, as I can't easily switch my microservices to the schema-retrieval MR (because docker). @milho001 If you can run it locally as a final check, then its good to go. Syntactically everything is fine
@s.a.vink It took me a while to figure out what you meant with 'schema-retrieval MR' as it was in a different repo, I would be helpful to put the link (graphpolaris/microservices/schema-retrieval!4) there instead. GitLab does nice formatting and everything :)
I took a quick look. Overall it is good, but there is a problem in case I switch between saveStates quickly. I may receive the stats of the wrong savestate (wrong schema), causing the schema data within redux to be badly populated (offsync). I'd recommend that instead of adding the data to the existing schema, you just add it to a new part of redux, which can be consumed by the components separatelly. This could be a Map of node->stats, so that its as fast as having the data within the schema structure.
An alternative is to only return the schema with the stats (so, make the call synchronous), but this would need more work and I think is less ideal than the first idea.