-
Notifications
You must be signed in to change notification settings - Fork 25
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
Conversation
CodSpeed Performance ReportMerging #6433 will not alter performanceComparing Summary
|
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) |
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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
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