…just like when you include a shared linked Component in a workflow, where you cannot modify that Component, it works the same way when you include it in another Component. You cannot modify a shared linked Component. You can only modify the source, and then re-save the Component.
D: I understand that, this makes sense, no issue here.
It’s one of the pain that I had to deal with when using Components within Components, but on the other hand, it’s also a sort of security, reminding you that you are trying to modify a shared linked Component that will impact other workflows that are using that Component.
D: I understand that, this makes sense, no issue here.
I try to avoid using Components within Components because of that, because I’d have to update 2 sources if I’m updating a Component used within a Component. Only in rare cases where I’m creating a wrapper Component that I do Components within Components. But I try to avoid it where possible.
D: I understand that, this makes sense, however it would be nice if KNIME had a routine/process/what so ever, that allowed to update the chain of components, that are identified: e.g. A workflow opens > asks for updating included linked components > identifies 2nd layer components, that are within those 1st layer components, in order to update the first layer component properly > DOES THE SAME thing as long as there are layers of linked components. KNIME could do this even in the background and prompt a result to the user what’s the situation and what the user wants to do about it, e.g. update all automatically, or let the user select, which to update and which to unlink, if allowed to.
For example, let’s say I can fetch articles from a data source only based on a date range. Everything else has to be filtered after the data is retrieved. I can have a Core Component called “Fetch All Articles” where the data is retrieved and common logic is applied, after which I may have wrapper Components such as “Fetch Articles By ArticleID”, and “Fetch this by AuthorID” where they would call the Core Component “Fetch All Articles” and apply filter by ArticleID for the “Fetch Articles By ArticleID” Component, and apply filter by AuthorID for the “Fetch this by AuthorID” Component.
Of course, if the user is going to do both kinds of fetch, then you don’t want to be running both wrappers, as they would both call the Core Component and retrieve the same data twice from the data source, in which case it’s better that the Core Component “Fetch All Articles” is used, along with manual filtering of AuthorID and ArticleID.
D: You are right, in this example, if “Fetch Articles By ArticleID” and “Fetch this by AuthorID” are close to each other within the visual interface, than it makes little sense, to call the same core process twice in advance e.g. “Fetch All Articles”. However, if both wrapper components are far from each other, or within different workflows but within components, then what would be the best practice, to carry the results from the core component towards the point, where it is needed, even if it is needed more than one or two times? In my original case, it is about a core component, that opens a data base session, and I need this session multiple times in different places of the rather complex workflow (maybe in the case of database session, there are other elegant solutions, which I am happy to read about). But another, common use case is e.g. a “DateManipulation”-linked-component, which has a simple user interface (see picture below). This can be used multiple times with different settings via the interface, and at best even within other LINKED components e.g. a ‘DataBaseSetting’ with a similar interface, setting the database credentials or other needed things. Both could be standardized and intensely used by me or others in multiple projects, and therefor at best linked.
Alternatively in this case, I can also build the 2 Components “Fetch Articles By ArticleID” and “Fetch this by AuthorID” without including the Core Component in them, but rather as Components that assume that the Core Component is called before calling them, and therefore can be built based on the expected results from the Core Component, hence avoiding to include a Component within a Component.
D: but see above, what if the wrapper components are far from each other?
The other issue I don’t like about shared Linked Components being used within other shared Link Components is if you need to somehow share your workflow to someone who does not have these Components or does not have the same workspace structure, Knime will complain that it cannot find the Linked Components, and it’s a pain to have to unlink these Components, especially those inside the Components.
D: would be easily avoided, if KNIME had a prompt when opening the workflow: "Those are the components within that workflow. This is the sub-list, which cannot be updated. What do you want to do? Find and relink them? Unlink them (all or a selection via check box)?"
But you get the idea for the use of Components within Components, the pros and cons.
D: yes, I get your point, but it is either a pity that it is not easily possible, what is possible in other languages: define a function/procedure/etc. and reuse it, where ever needed, even within myself.
I hope I do not confuse to much, and I am happy about your support.