Optimized workflow reordering and insert at cursor #1324
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
glopesdev
added
feature
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR refactors the workflow graph representation as a collection where nodes can be individually accessed by index. This allows much faster reordering of workflow nodes, and enables ordered insertion at cursor position.
It also lays down the foundation for interpreting the workflow directly as an expression tree, where the roots are sinks, i.e. nodes with no successors, and leaves are sources.
Branch points are interpreted as anonymous scoped publish operators. The publish closure for each branch is resolved by taking the smallest subset of nodes dependent on the branching source. A node is dependent on a branching source if it lies on a direct dependency path from the node to the source, and there exists at least one other node in the workflow which also lies in a direct dependency path to the same branching source, and there are no shared nodes between the two paths except for the branching source itself.
In other words, a publish branch is closed when all branches are merged back to a common trunk. If there is no such common trunk, the branch is closed around the connected set of nodes to which the branch belongs. Nodes belonging to disjoint sets are not affected by this branching behavior.
Fixes #1014
Fixes #1129
Fixes #1317
Fixes #1345