apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amol Kekre <a...@datatorrent.com>
Subject Re: empty operator/stream/module names
Date Fri, 05 Aug 2016 16:04:19 GMT
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 <prad@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 <tushar@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 <yogidevendra@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 <tushar@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 <
> sanjay@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" <ram@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.rozov@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
> > >> >     >
> > >> >
> > >> >
> > >> >
> > >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message