Pradeep, The clash is if an user explicitly names the operator later with same formula we have (say a typo by user). This is a name scoping issue, and one way to solve it is by Stram using a character/delimiter in auto generated name, that is explicitly disallowed in user specified names.
Anyone knows how compilers do name mangling for function signatures? Same issue. I am guessing it is "disallowed delimiter/character" method (for eg "@"). Thks Amol On Fri, Aug 5, 2016 at 12:04 AM, Pradeep A. Dalvi <[email protected]> wrote: > Just curious. If we choose an approach where system generated name for > operator/module =~ operator/module class name + some identifier (index of > operator in DAG), how difficult would that be? > > As it is done elsewhere, we certainly would have to pick user defined names > first and then work on system generated names. > > Also another possible approach could be of having system-generated > identifiers and (user definable) names. If name is not given by user, > system generated identifier would be used as name. > > --prad > > On Thu, Aug 4, 2016 at 11:50 PM, Tushar Gosavi <[email protected]> > wrote: > > > System generated names can also be problematic. User given name > > collides with system generated names. we can not generate the name > > when component is added > > in the DAG. we will have to wait till all components are added then > > generate the names. I am -0 on system generated names. Providing a > > name to operator/stream/module is > > not much of an effort. +1 on not supporting null/empty > > operator/stream/module names. > > > > -Tushar. > > > > > > On Fri, Aug 5, 2016 at 12:06 PM, Yogi Devendra <[email protected]> > > wrote: > > > 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 > > >> > > > > >> > > > >> > > > >> > > > >> > > >
