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

KNIME Analytics Platform
5

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

5 Likes