You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oozie.apache.org by "Daniel Becker (JIRA)" <ji...@apache.org> on 2017/08/25 08:07:01 UTC
[jira] [Comment Edited] (OOZIE-3032) API for workflows: decision
nodes autogeneration (difficult cases)
[ https://issues.apache.org/jira/browse/OOZIE-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16141351#comment-16141351 ]
Daniel Becker edited comment on OOZIE-3032 at 8/25/17 8:06 AM:
---------------------------------------------------------------
An idea on how to solve this:
We join all of E, F, G and H in the (partial) graph, and insert one or more extra decision nodes _after_ the join node. These extra decisions use the EL function *wf:transition* to query which transition was taken and make a decision on where to go on based on that.
The question arises what we do with nodes that can be reached through a conditional path but transition "nowhere", meaning it should go to "end". We often cannot just transition to "end" because it may be embedded in (multiple) fork / joins and we have to satisfy the Oozie constraints.
What we could do is insert a temporary node in the graph that means "go to the next join and after that, make a decision and go to the next join again until we reach "end"". This has the disadvantage that the number of decision nodes goes up depending mainly on the number of fork / join pairs around the original decision node.
was (Author: daniel.becker):
An idea on how to solve this:
We join all of E, F, G and H in the (partial) graph, and insert one or more extra decision nodes _after_ the join node. These extra decisions use the EL function *wf:transition* to query which transitin was taken and make a decision on where to go on based on that.
The question arises what we do with nodes that can be reached through a conditional path but transition "nowhere", meaning it should go to "end". We often cannot just transition to "end" because it may be embedded in (multiple) fork / joins and we have to satisfy the Oozie constraints.
What we could do is insert a temporary node in the graph that means "go to the next join and after that, make a decision and go to the next join again until we reach "end"". This has the disadvantage that the number of decision nodes goes up depending mainly on the number of fork / join pairs around the original decision node.
> API for workflows: decision nodes autogeneration (difficult cases)
> ------------------------------------------------------------------
>
> Key: OOZIE-3032
> URL: https://issues.apache.org/jira/browse/OOZIE-3032
> Project: Oozie
> Issue Type: Sub-task
> Components: client
> Reporter: Andras Piros
> Attachments: 20170825093712-incoming-conditional-branches-from-different-decisions-workflow.png, partial_dag.png
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)