when a metanode contains a direct connection between an input and an output connector without a node in between, and an attempt is made to convert this metanode into a component, the metanode disappears completely. Even “undo” cannot bring it back.
I get it now. Tnx for sharing example.
A bit confused cause not sure why design like this? Intuitively this would implicate that there is another operation/node inside metanode between Node 1 and Node 6.
why design like this? Purely for esthetic reasons. My workflow carries a data table and a second table with metadata on the columns of the first table from one node to the next, to the next, to the next… This ends up looking a bit like this:
In a few of these metanodes i don’t actually use the metadata table. In those cases I could construct the workflow like this:
Hmmm… I would rather go for bottom design. Both aesthetically and practically. Would use curved connections and if I want to inspect upper stream I know I don’t have to open (Meta)Node 11 cause there is nothing to inspect
Well, actually, there is a bit more than esthetical reasons to do it like this. The upper and lower tables are intimately connected, as most operations on the lower table require information from the upper table. As such, the two tables should stay “in sync”. As Knime does not offer a way to store two tables in some type of object*, or to store column metadata in the data table, keeping data table and metadata table spatially close together in the workflow layout is the only way to communicate to the workflow designer that the two tables belong together.
*at least not without diving into Knime node development and developing a new connector type