Skip to content

update rel cypher queries for migrated kind nodes #6433

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
May 12, 2025

Conversation

ajtmccarty
Copy link
Contributor

@ajtmccarty ajtmccarty commented May 9, 2025

a test depends on this PR in the sdk opsmill/infrahub-sdk-python#403
will update the commit pointer once that PR is merged

updates to several Relationship-related cypher queries to correctly handle nodes that have had their kind or inheritance updated (in which case multiple nodes exist with the same UUID)

basically a more generic version of #6421

@github-actions github-actions bot added the group/backend Issue related to the backend (API Server, Git Agent) label May 9, 2025
Copy link

codspeed-hq bot commented May 9, 2025

CodSpeed Performance Report

Merging #6433 will not alter performance

Comparing ajtm-05082025-rel-query-updates (849c1ce) with stable (94beb5d)

Summary

✅ 10 untouched benchmarks

@ajtmccarty ajtmccarty marked this pull request as ready for review May 9, 2025 01:29
@ajtmccarty ajtmccarty requested a review from a team as a code owner May 9, 2025 01:29
UNION
WITH rl
MATCH (rl)<-[active_edge:IS_RELATED]-(n)
WHERE ((active_edge.branch IN $branch0 AND active_edge.from <= $time0 AND active_edge.to IS NULL)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how is this logic different from the branch filter we are usually using ?
also would it make sense to centralize this logic in order to reuse it, similar to what we are doing with the branch filters ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the problem with the current logic is that if there are multiple edges returned by this part of the subquery

MATCH (rl)<-[active_edge:<EDGE_TYPE>]-(n)
WHERE %(active_rel_filter)s AND active_edge.status = "active"

then this will always return the active edge, even a more recent deleted edge exists

as for centralizing this logic somewhere, I think that might be valuable as part of the cypher query engine we've discussed before, but I don't think there's a good place for it right now

@ajtmccarty ajtmccarty merged commit f16e7c8 into stable May 12, 2025
33 checks passed
@ajtmccarty ajtmccarty deleted the ajtm-05082025-rel-query-updates branch May 12, 2025 20:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
group/backend Issue related to the backend (API Server, Git Agent)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants