Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parameter explorations should be migrated through upgrades if possible #695

Open
dakoop opened this issue Aug 8, 2013 · 2 comments
Open

Comments

@dakoop
Copy link
Member

dakoop commented Aug 8, 2013

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.

@dakoop
Copy link
Member Author

dakoop commented Aug 8, 2013

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.

@rexissimus
Copy link
Member

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.

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

No branches or pull requests

3 participants