Ordering of patches with cycles during upload #2524
Conversation
aditya-07
changed the title
|
Is this ready for review ? |
There was a problem hiding this comment.
What if we use Strongly Connected Components (SCC) ?
- Identify the SCCs
- Consolidate all nodes in each SCC into a supernode.
- Then apply the same topological sorting
So for following graph:-
1 -> 2, 3
2 -> 4, 5
4 -> 1
5 -> 6
7 -> 8, 9
8 -> 7
SCC = [{1,2,4}, {7, 8}]
We can have the topological sort as - [{3}, {6}, {5}, {1, 2, 4}, {9}, {7, 8}]
Current solution is also right but the above solution has more improvements:-
- Time complexity is one-fourth (from first look).
- In current approach the weakly-connected-components will go in one bundle if there is a cycle. Whereas in the above approach only the SCC will go in one bundle -> Reduces the size of the bundle a lot.
|
It's the Tarjan's Algorithm: https://www.geeksforgeeks.org/tarjan-algorithm-find-strongly-connected-components/ |
| data class IndividualMapping(val patchMapping: PatchMapping) : OrderedMapping | ||
|
|
||
| /** | ||
| * [CombinedMapping] contains weakly connected [PatchMapping]s where one or more [PatchMapping]s |
There was a problem hiding this comment.
| * [CombinedMapping] contains weakly connected [PatchMapping]s where one or more [PatchMapping]s | |
| * [CombinedMapping] contains strongly connected [PatchMapping]s where one or more [PatchMapping]s |
| @@ -67,3 +67,20 @@ internal data class PatchMapping( | |||
| val localChanges: List<LocalChange>, | |||
| val generatedPatch: Patch, | |||
| ) | |||
|
|
|||
| /** Structure to help describe the cyclic nature of ordered [PatchMapping]. */ | |||
| internal sealed interface OrderedMapping { | |||
There was a problem hiding this comment.
i think there is no order in this structure itself - so maybe patch mapping group is a better name - or something similar?
| @@ -139,4 +156,138 @@ internal object PatchOrdering { | |||
| adjacencyList.keys.forEach { dfs(it) } | |||
| return stack.reversed() | |||
| } | |||
|
|
|||
| private fun stronglyConnectedComponents(diGraph: Graph, nodesCount: Int): List<List<Node>> { | |||
There was a problem hiding this comment.
optionally - you can separate all the logic related to scc to a separate class - and try to write it as an internal api.
| // reduce them to a single node | ||
| // replace the ssc nodes with super node | ||
| oldGraph.forEach { | ||
| // println(it.key) |
There was a problem hiding this comment.
| // println(it.key) |
| // Remove any cyclic dependency from connected components. | ||
| // reduce them to a single node | ||
| // replace the ssc nodes with super node |
There was a problem hiding this comment.
reformat this please (capitalise, punctuation etc)
There was a problem hiding this comment.
please udpate the unit tests here
| * Since a [UrlUploadRequest] can only handle a single resource request, the | ||
| * [OrderedMapping.CombinedMapping.patchMappings] are flattened and handled as | ||
| * [OrderedMapping.IndividualMapping] mapping to generate [UrlUploadRequestMapping] for each | ||
| * [PatchMapping]. |
There was a problem hiding this comment.
this is good. but can you also add that we could potentially make this illegal in the future and explicitly introduce configurations for referential integrity on the server side.
and maybe just add a little bit to explain that single resource requests won't be able to handle resources referencing each other if the server is strict about referential integrity.
IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).
Fixes #2500
Description
Alternative(s) considered
Have you considered any alternatives? And if so, why have you chosen the approach in this PR?
Type
Choose one: Bug fix
Screenshots (if applicable)
Checklist
./gradlew spotlessApplyand./gradlew spotlessCheckto check my code follows the style guide of this project../gradlew checkand./gradlew connectedCheckto test my changes locally.