âŚ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.
