+1 Sometimes this context is required. We shouldn't change any default behaviour other than making this config available.
-Priyanka On Wed, Dec 20, 2017 at 5:32 AM, Pramod Immaneni <pra...@datatorrent.com> wrote: > The external system recording was just an example, not a specific use case. > The idea is to provide comprehensive information to populateDAG as to the > context it is being called under. It is akin to the test mode or simulate > flag that you see with various utilities. The platform cannot control what > populateDAG does, even without this information, in multiple calls that you > mention the application can return different DAGs by depending on > any external factor such as time of day or some external variable. This is > to merely provide more context information in the config. It is upto the > application to do what it wishes with it. > > On Tue, Dec 19, 2017 at 2:28 PM, Vlad Rozov <vro...@apache.org> wrote: > > > -0.5: populateDAG() may be called by the platform as many times as it > > needs (even in case it calls it only once now to launch an application). > > Passing different parameters to populateDAG() in simulate launch mode and > > actual launch may lead to different DAG being constructed for those two > > modes. Can't the use case you described be handled by a plugin? > > > > Thank you, > > > > Vlad > > > > > > On 12/19/17 10:06, Sanjay Pujare wrote: > > > >> +1 although I prefer something that is more enforceable. So I like the > >> idea > >> of another method but that introduces incompatibility so may be in 4.0? > >> > >> On Tue, Dec 19, 2017 at 9:40 AM, Munagala Ramanath < > >> amberar...@yahoo.com.invalid> wrote: > >> > >> +1 > >>> Ram > >>> On Tuesday, December 19, 2017, 8:33:21 AM PST, Pramod Immaneni < > >>> pra...@datatorrent.com> wrote: > >>> > >>> I have a mini proposal. The command get-app-package-info runs the > >>> populateDAG method of an application to construct the DAG but does not > >>> actually launch the DAG. An application developer does not know in > which > >>> context the populateDAG is being called. For example, if they are > >>> recording > >>> application starts in an external system from populateDAG, they will > have > >>> false entries there. This can be solved in different ways such as > >>> introducing another method in StreamingApplication or more parameters > >>> to populateDAG but a non disruptive option would be to add a property > in > >>> the configuration object that is passed to populateDAG to indicate if > it > >>> is > >>> simulate/test mode or real launch. An application developer can use > this > >>> property to take the appropriate actions. > >>> > >>> Thanks > >>> > >>> > >>> > > >
