1. I am not clear how end user will configure properties for operators with system generated names. 2. If we are going for system generated names we should make sure that names are deterministic and consistent. An operator should get same system generated name for multiple runs. 3. System generated names should be human readable and reflect underlying operator. For example, name should be something like HDFSOutput_019 rather than Operator_019.
~ Yogi On 5 August 2016 at 10:47, Tushar Gosavi <[email protected]> wrote: > When we need to change plan dynamically through dtcli, we need name to > delete or attach to existing operator/port. I am fine with using > system generated name when user do not provide name while adding > operator/module/stream. > > -Tushar. > > > On Thu, Aug 4, 2016 at 10:33 PM, Sanjay Pujare <[email protected]> > wrote: > > I differ. For the UI to render a DAG the names are useful, but if the > name is not required by the engine i.e. the engine is able to execute your > application fine with empty or null strings as names, is there any reason > to make them mandatory? > > > > On the other hand, we can come up with a scheme for system generated > names when the caller doesn’t provide a name. I have some ideas. > > > > > > On 8/4/16, 9:48 AM, "Munagala Ramanath" <[email protected]> wrote: > > > > I don't see any reason to allow either. > > > > Ram > > > > On Thu, Aug 4, 2016 at 8:51 AM, Vlad Rozov <[email protected]> > wrote: > > > > > Currently addOperator/addStream/addModule allows both null and > empty > > > string in the operator/stream/module names. Is there any reason to > allow > > > empty string? Should empty string and null be disallowed in those > APIs? > > > > > > Vlad > > > > > > > > > >
