Mailing-List: contact dev-help@apex.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@apex.incubator.apache.org
Date: Fri, 29 Jan 2016 05:59:39 +0000 (UTC)
From: "Tushar Gosavi (JIRA)" <jira@apache.org>
To: dev@apex.incubator.apache.org
Message-ID: <JIRA.12919181.1436367810000.246236.1454047179937@Atlassian.JIRA>
In-Reply-To: <JIRA.12919181.1436367810000@Atlassian.JIRA>
References: <JIRA.12919181.1436367810000@Atlassian.JIRA>
 <JIRA.12919181.1436367810000@arcas>
Subject: [jira] [Updated] (APEXCORE-3) Ability for an operator to populate
 DAG at launch time
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/APEXCORE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tushar Gosavi updated APEXCORE-3:
---------------------------------
    Attachment: ModuleSupport.pdf

> Ability for an operator to populate DAG at launch time
> ------------------------------------------------------
>
>                 Key: APEXCORE-3
>                 URL: https://issues.apache.org/jira/browse/APEXCORE-3
>             Project: Apache Apex Core
>          Issue Type: New Feature
>            Reporter: Amol Kekre
>            Assignee: Vlad Rozov
>            Priority: Critical
>              Labels: roadmap
>             Fix For: 3.3.0
>
>         Attachments: ModuleSupport.pdf
>
>
> Apex should have an operator API that lets the operator generate DAG during launch time. This will mean the following
> - Logical DAG will have one operator. This is the operator that will generate a DAG underneath
> - Physical plan will have the DAG generated by the operator
> - Execution plan will mimic physical plan + container location etc.
> For example lets say we have three operators in a DAG (app) A->B->C
> B during launch time generates a DAG B1->B2->B3, then the physical plan will be
> A->B1->B2->B3->C
> This should work irrespective of number of ports, etc. A typical flattening. The operators inside of B (B1, B2, B3) should have properties and attributes just as any. Users should be able to access these at run time and compile time. B itself should support properties and attributes that B1, B2, B3 can inherit from.
> This is a very critical feature as it will open up users to plug-in their own engines and still take up complete operability support from Apex engine.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)