Broken links when using nested shared components from different workspace tree levels

[dobo]

Hi!

I created this very complex workflow that includes many nested shared components. I am a big fan of relative paths for that purpose, however if you nest shared components and use relative paths, then the update links break if you include the outer shared component from different levels of the project tree. This prevents me from creating a very flexible setup and I would actually need to use mountpoint relative links in order for this to work. If then somebody imports the project at a different level in the local workspace tree, all those links would break.

Therefore my question is, whether you could also include node-relative links in the type selection, because this would fix my issue:

The setup of my demo workflow looks like this:

Which I also upload to this post:
Nested Shared Components Issue.knar (52.1 KB)

The workflow A & B (at different levels of the project tree) contain the shared component “Complex DB Functionality”:

The “Complex DB Functionality” contains the nested shared component “DB Query”:

In this setup, the updates of the shared nodes will only work in either Workflow A or Workflow B but not in both because one will always have the wrong workflow relative path in the nested component:

So the solution in such cases would be to have node relative links (knime://knime.node/…)in the shared components for the nested component, which will let KNIME search at the right location for updates in any case.

On a side note I found this information at this link:

This seems not to be the case on my windows instances!

[dobo]

So, interestingly I also ran into update issues when I use mountpoint relative links. The link seems to look correct but the update fails. There really seems to be a bug. Maybe related to this post?

Then I found out that absolute links have changed a bit as well as they now refer to the local workspace, which I find great and might solve my issues to some extent. In previous versions, the absolute link was based on my file system, which made it impossible to share workflows (that update correctly) with colleagues.

[dobo]

This is weird, it seems through heavily rearranging my multiple workflow and shared component setup the links (which the automatic updater after opening a workflow uses) became inconsistent. I am missing two dots ..\ in the link shown below in order for the update check to resolve quickly. I will see the same error message even when adding the node freshly by pulling it in from the KNIME Explorer, after restarting KNIME and opening the workflow again:

WARN CheckUpdateMetaNodeLinkAction Unable to check for update on node "Write to TP LAB DB 0:0": Can't read metanode/template directory C:\Software\knime-workspace_4.1.1\TP LAB\Segmentation\Step 1 - Data Integration\Custom Step 1.1 - D1 COSMOS\..\..\TP LAB Database\TP LAB DB Connector

And even more funny, if I do the update of node links manually (right click -> component -> update Link) it works!?

[Alice_Krebs]

Hi @dobo

Thanks for letting us know. We’re on it, I’ll keep you posted

Best,
Alice

[hornm]

Hi @dobo,

first of all, thanks for reporting this issue! Because it is something we definitely should improve.

Here’s the problem summary (for other readers and for us to be able to improve the situation):

Setup:

• Components
  • Component 1
  • Component 2
    contains and links Component 1
• Workflow Group 1
  • Workflow Group
    • Workflow A
      contains and links Component 2
• Workflow Group 2
  • Workflow B
    contains and links Component 2

Problem: The (recursive!) update of the linked component (Component 2) in one of the two workflows (Workflow A or B) doesn’t work if and because the Component 1 (which is part of Component 2) has a workflow-relative link pointing to ‘no man’s land’.

Explanation: If the link of Component 1 (which is part of Component 2) is knime://knime.workflow/../../Components/Component 1 then the component update will work for Workflow B but not for Workflow A. Because for every component update (of a component with a workflow-relative link) the workflow itself is taken as origin (hence, workflow-relative). Consequently, when trying to update Component 1 as part of Workflow B, we would look for a component in /Workflow Group 1/Workflow Group/Workflow A/../../Components/Component 1 which is, if we resolve those ‘relative’ path fragments, actually /Workflow Group1/Components/Component 1 -> which doesn’t exist.
To make it work for Workflow A the link would need to look like knime://knime.workflow/../../../Components/Component 1 - but then it doesn’t work for Workflow B (relative to Workflow B the link would expect the Component 1 ‘above’ the directory’s root!).

(not really satisfying) Workarounds :

• use mountpoint-relative links instead of workflow-relative links for linked components that are part of other linked components; however in this case we loose the flexibility actually desired by @dobo because the original components need to be at the very same position relative to the mountpoint (in the example at /Components)
• use a workflow-relative link for the nested linked component (i.e. Component 1) but make sure that the number of /../ in workflow-relative link for Component 1 (in Component 2) sort of matches the ‘relative hierarchy level’ of the workflow which contains/links the parent component (i.e. Component 2). That is all workflows using/linking Component 2 (which contains this problematic workflow-relatively linked Component 1) need to be on the same level in the directory hierarchy relative to Component 1 (they don’t need to be in the same directory). For the above example, Workflow A and B are either at (/Workflow Group 1/Workflow Group/Workflow A and /Workflow Group 2/Workflow Group/Workflow B)
  or (/Workflow Group 1/Workflow A and /Workflow Group 2/Workflow B). This gives the flexibility that the Workflows and Components can be arbitrarily be moved around as long as they are remain at the same position relative to each other.

Possible solution (i.e. for future implementation):
If workflow-relatively linked components are part of another linked component they should always use the ‘closest’ (in the component hierarchy) linked component (here it’s the direct parent) as origin instead of the workflow they are part of. This essentially turns a workflow-relative link into a ‘closest-linked-component-parent’ link).
I created ticket internally. Though I can’t promise anything on when and how we are going to solve it.

Okay, this response turned out to be longer and unfortunately more complicated than I anticipated. Just let me know if more clarification is required.

Best,
Martin