Agreed, we either do this such that we handle all corner cases of simply disallow empty string. I am now inclined to simply disallow empty string as ramification of characters like "@" could be bad.
Thks Amol On Fri, Aug 5, 2016 at 9:37 AM, Vlad Rozov <v.ro...@datatorrent.com> wrote: > Introducing "invalid" characters into user provided names will lead to > - possible incompatibility with the existing applications as currently "@" > and other special characters are considered to be valid > - confusion with end user, why it is not possible to reuse system > generated name > > I am more inclined to disallowing null and empty strings and not providing > system generated names. As long as DAG is created by a developer, DAG is > likely to have only handful number of operators and it is not a big deal to > provide meaningful names. Once we talk about automatic DAG generation by > higher level API or an execution plan generator, it will be responsibility > of the corresponding system to generate meaningful names. > > Vlad > > > On 8/5/16 09:04, Amol Kekre wrote: > >> 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 <p...@apache.org> >> 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 <tus...@datatorrent.com> >>> 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 <yogideven...@apache.org >>>> > >>>> 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 <tus...@datatorrent.com> >>>>> >>>> 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 < >>>>>> >>>>> san...@datatorrent.com> >>> >>>> 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" <r...@datatorrent.com> >>>>>>> >>>>>> wrote: >>> >>>> I don't see any reason to allow either. >>>>>>> >>>>>>> Ram >>>>>>> >>>>>>> On Thu, Aug 4, 2016 at 8:51 AM, Vlad Rozov < >>>>>>> >>>>>> v.ro...@datatorrent.com> >>>> >>>>> 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 >>>>>>> > >>>>>>> >>>>>>> >>>>>>> >>>>>>> >
