Skip to content
This repository has been archived by the owner on Jul 21, 2020. It is now read-only.

Handle parallel element collapse #24

Open
mccalluc opened this issue Oct 31, 2019 · 0 comments
Open

Handle parallel element collapse #24

mccalluc opened this issue Oct 31, 2019 · 0 comments

Comments

@mccalluc
Copy link
Collaborator

Here are notes from Alex:

I need to dig in to figure out how is done but basically we add more vars to meta (step.meta I think) on backend like "is_group", "workflow", and "grouping_property", and then like, combine them on frontend, in a weird way

For all steps/files that have those 3 props equal to each other

Is pretty shoddy, was kind of 1 of later things added after everything else was working so kinda hacked it in rather than designed it in
That part would definitely want to refactor in conjunction with backend/caching updates, so that all grouping/ungrouping is performed on frontend instead
Currently the backend logic that adds that step.meta stuff is also a performance enhancement that avoids tracing history of those parallel steps

https://data.4dnucleome.org/experiment-set-replicates/4DNESMU2MA2G/#graph-section
The "8 similar files" group nodes are grouping those 8 similar files and their histories (steps output from etc)

Backend logic = if same file type, same input argument, and output from same workflow (steps are workflow-runs == instances of workflows), then is assumed to be parallel (and add those 3 aforementioned properties to meta) (edited)

Part of refactoring might be to like remove those group nodes and replace with something else (box showing more graphs or somit, maybe the actual graph(s) but minimized (since we'd have that data on frontend in future)), idk. But yeah that part is probably most subject to be changed at some point (re: any frontend/repo changes)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant