You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because parameter explorations are identified by the version of the workflow they were created for, an upgrade will cause all parameter explorations for the upgraded version to disappear since the upgrade has a number version identifier. In order to migrate parameter explorations, we need to obtain a remap for the module ids from the old modules to the upgraded versions. This is not possible in general because upgrades can do upgrades that map modules in one-to-many or many-to-one manner. However, when they use 1-1 maps only, we can find the remap which will often (though not always) work with the explorations. There could still be cases where function names, for example, changed.
The text was updated successfully, but these errors were encountered:
The underlying logic exists in master as of commit 29f072a, but the interaction is still clunky. We really want to have the list of current parameter explorations to know about _delayed_paramexps in the controller when the current_pipeline was generated from an upgrade.
In addition, it might be interesting to consider showing parameter explorations from previous versions when possible. For example, we just traverse up the tree to all parameter explorations along the path to the root. If the exploration can still be applied to the current pipeline, we show it in the list of past explorations.
It looks like mashups have the same problem, the module id:s needs to be updated. Wi this method work for those as well?
We could also reference modules by their type and number(if there are more than one of the same type). This would work as long as upgraded id:s are upgraded in the same order, the upgrade is 1:1, and the module name is not changed. upgrades would then automatically work. But I am not sure it will work when we switch to uuid:s.
A named parameter exploration can be dragged from the project view and dropped to any other version. It will work as long as the modules it uses have not changed (or upgraded). To have pe:s follow versions, we can do what mashups do, ask the user if they want to import the pe:s from a previous version.
Because parameter explorations are identified by the version of the workflow they were created for, an upgrade will cause all parameter explorations for the upgraded version to disappear since the upgrade has a number version identifier. In order to migrate parameter explorations, we need to obtain a remap for the module ids from the old modules to the upgraded versions. This is not possible in general because upgrades can do upgrades that map modules in one-to-many or many-to-one manner. However, when they use 1-1 maps only, we can find the remap which will often (though not always) work with the explorations. There could still be cases where function names, for example, changed.
The text was updated successfully, but these errors were encountered: