Options
workflow execution modes: Knime vs RM
Contributor II
Hi,
in RM workflows are always executed completely. But here's how Data Mining always works (at least for my colleagues and me): You start with a data-source and a few operators. You execute it and that drag new operators to he workbench. Than you just want to execute just those new operators (because everything else is already "green" but RM always reruns the complete workflow. Is there any means to run just the not-yet-"green" operators?
In Knime the user needs to reset a workflow to make it to execute completely from scratch. What is especially cool there is the user can click on a node and say "execute" which will cause Knime to execute the dependency tree (if not yet done) and only the nodes. Other unaffected pathways remain as they are.
Is there a way to mirror this feature somehow in RM? Is something similar planned for the future?
-Holger
in RM workflows are always executed completely. But here's how Data Mining always works (at least for my colleagues and me): You start with a data-source and a few operators. You execute it and that drag new operators to he workbench. Than you just want to execute just those new operators (because everything else is already "green" but RM always reruns the complete workflow. Is there any means to run just the not-yet-"green" operators?
In Knime the user needs to reset a workflow to make it to execute completely from scratch. What is especially cool there is the user can click on a node and say "execute" which will cause Knime to execute the dependency tree (if not yet done) and only the nodes. Other unaffected pathways remain as they are.
Is there a way to mirror this feature somehow in RM? Is something similar planned for the future?
-Holger
0
Answers
636 if (getExecutionMode() != ExecutionMode.ONLY_DIRTY) {
This somehow looks like the feature I would like to see in RM. Any comments on this one?
-Holger
as you already saw in the code, this feature is definitively planned for the future. And if we would have more paying customers and less complaining users needing constant effort in support, we would have managed to implement it for RapidMiner 5 already, because then we would haven been able to hire another software developer. Unfortunately this is not the case.
Greetings,
Sebastian
My problem is not paying money to you. My problem is that according to rapid-i.com, the support-contracts ensure only bug-fixes and do not include feature requests. Paying for features would be a nice extension to your current business model, as it would allow us to actually get the features we need to do our work. In the current situation I'm providng a custom build of RM for my collegues to fix some issues like Mac-support, Plugin-loading, etc. because this is out of scope of the support contracts you're offering.
The other option IMHO is code contribution. As RM is opensource it's straightforward for users to improve it and to submit patches. So as it looks like the issue described above has been already partially addressed. What is actually missing? Just a operator-context-menu entry for "Reset Operator" which would render it as dirty and would go through all the output-tree operators to flag them as dirty as well? I could you help with that, if you've a shortage of devs. :-) Clearly we should figure out the specs in more detail together, before I actually start coding.
What do you think? (For sure I would prefer to pay you for the execution mode, if there's a reasonable price given the effort necessary to implement it).
Best, Holger
Keith