when dragging and dragging & dropping i.e. a CSV, XML, Excel file into Knime it automatically configures the corresponding node. Sometimes, i.e. instead of a File Reader node, a simple file reader or another one is preferred.
It might be nice, when replacing an already configured node, that some basic configuration like input / file locations or variables are kept in the configuration of the new node. This could provide a valuable shortcut speeding up workflow designs.
got another idea. When nodes get deprecated / replaced by new ones, this functionality might become handy, However, what about an auto update / replace function.
Just image you have a workflow with thousand of nodes and would be required to manually search, replace and reconfigure the deprecated nodes. Having a auto update feature which takes care of it and provides a log with missing or incompatible configurations would just be awesome.
if deprecated nodes work as expected (and I don’t see why they wouldn’t) and you don’t need functionality from new node(s) I wouldn’t waste time doing replacement being it by hand of automatically (and from experience automation processes always need manual intervention at some point ).
What is the purpose of marking them as deprecated in the first place then? I‘d expect better performance, higher reliability because bugs getting fixed for non-deprecated only I assume and well, as you mentioned yourself, new features.
Hm, in general terms of programming depreciation means that at some point it will go away, not be available anymore and hence must be updated at some point.
While having a fast pace in new stuff is good, a major gripe I have it that updating workflows to new version is a very tedious and time consuming. So if above interpretation is incorrect and the nodes can actually be used for a long time it would be good to have this somewhere documented what is actually meant by “deprecated” in terms of nodes.
we are only deprecating nodes if we are replacing them with a new version, which would break the backward compatibility. That all KNIME workflows are working in future KNIME Versions is a very important topic for us, we actually wrote even a blog post about it.
I can totally underline Ivans Opinion. It is not mandatory to replace the nodes. However if you touch a workflow, replacing them will give you more options. And for example in the case of the database nodes or our soon* to be released new File Handling nodes, more performance.
*soon here means Sunday the the 6th of December with the 4.3 release
Iris, you said you are marking nodes as deprecated “if we are replacing them with a new version”. This actually complements what Joos said:
that updating workflows to new version is a very tedious and time consuming. So if above interpretation is incorrect […]
Ipazin: deprecated nodes work as expected (and I don’t see why they wouldn’t) and you don’t need functionality from new node(s) I wouldn’t waste time doing replacement being it by hand of automatically
[…] and the nodes can actually be used for a long time it would be good to have this somewhere documented what is actually meant by “deprecated” in terms of nodes.
In other words, nodes become deprecated as you said invalidating the statement from Ipazin and seconding the one from Joos. Henceforth, deprecated nodes should, in the best of interest of everyone, get updated in a more convenient way. “Staying put” doesn’t mean things getting frozen in time but rather enforcing regression as Knime itself advances which would, inevitably, cause failure.
This failure, since Knime became a vital element of so many corporations, can cause unforeseeable incidents. Wouldn’t you agree?
Don’t get me wrong, I don’t want to be pushy but for myself I embrace and “update early”, which steadily introduces fixes and features in a progressive way, ever since. “Failing early” is much better, as failure can never be prevented, though. But failure in case of major version jumps is much worse compared to those upon smaller incremental changes which are much better comprehensible.