Hi There,
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.
Best
Mike
Hi @mw
yes agreed. We considered this as well since quite some time. But it never made it to the top of the list.
I will push this a little bit 
Hi @Iris,
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.
Best
Mike
Hello @mw,
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 
).
Br,
Ivan
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.
Hello @mw,
Iâm not a developer but seems to me nodes get deprecated when backwards compatibility can not be fulfilled. (Probably there are more reasons.)
Br,
Ivan
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.
Hi @mw
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
Good morning @Iris and @kjariwala,
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.
What do you / does everyone think?
Best
Mike
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.