Fix order of sorting for cyclic dependencies #481
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix order of sorting for cyclic dependencies where multiple dependencies are assumed to always
go after the cyclic one
In the test case:
Lets assume none of the FK allow cascading deletes
Removing Node 1 would be blocked by Node 2
Removing Node 2 would be blocked by Node 3 and Node 5
Removing Node 3 would be blocked by Node 4 -> cyclic through 4 -> 2 -> 3
Removing Node 4 would be blocked by Node 2 -> cyclic through 2 -> 3 -> 4
Removing node 5 is not blocked by any nodes
So We need to first remove Node 5, which is not blocked by any node
And Node 1 is not part is a cyclic dependency itself, but Node 2 references it, so Node 1 must always come somewhere after Node 2, which is part of a cyclic dep so Node 1 should then come after the other nodes
The rest of the nodes [2, 3, 4] are locked in cyclic dep. so we cannot really resolve them in a favourable way, unless we
try to identify which dependencies are blocking and which ones are not (deleting/nulling FKs or not), only listing the blocking dependencies should also resolve the issue, making the chance of success higher, this is however done by the Purger