You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apex.apache.org by Vlad Rozov <v....@datatorrent.com> on 2016/08/04 15:51:05 UTC
empty operator/stream/module names
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
Re: empty operator/stream/module names
Posted by Pramod Immaneni <pr...@datatorrent.com>.
I don't see a reason to have it.
On Thu, Aug 4, 2016 at 8:51 AM, Vlad Rozov <v....@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
>
Re: empty operator/stream/module names
Posted by Amol Kekre <am...@datatorrent.com>.
I agree with Sanjay. Error should be what the engine cannot do without. The
lesser work an user can get away with (a choice for a forced option) the
better. So if users want they can name these objects, but if they don't it
still works.
Thks
Amol
On Thu, Aug 4, 2016 at 10:03 AM, Sanjay Pujare <sa...@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" <ra...@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....@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
> >
>
>
>
>
Re: empty operator/stream/module names
Posted by Amol Kekre <am...@datatorrent.com>.
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....@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 <pr...@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 <tu...@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 <tu...@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" <ra...@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
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>
Re: empty operator/stream/module names
Posted by Vlad Rozov <v....@datatorrent.com>.
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 <pr...@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 <tu...@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 <yo...@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 <tu...@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\u2019t provide a name. I have some ideas.
>>>>>>
>>>>>> On 8/4/16, 9:48 AM, "Munagala Ramanath" <ra...@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
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
Re: empty operator/stream/module names
Posted by Amol Kekre <am...@datatorrent.com>.
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 <pr...@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 <tu...@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 <yo...@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 <tu...@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" <ra...@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
> > >> > >
> > >> >
> > >> >
> > >> >
> > >>
> >
>
Re: empty operator/stream/module names
Posted by "Pradeep A. Dalvi" <pr...@apache.org>.
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 <tu...@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 <yo...@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 <tu...@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 <sa...@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" <ra...@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
> >> > >
> >> >
> >> >
> >> >
> >>
>
Re: empty operator/stream/module names
Posted by Tushar Gosavi <tu...@datatorrent.com>.
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 <yo...@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 <tu...@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 <sa...@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" <ra...@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....@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
>> > >
>> >
>> >
>> >
>>
Re: empty operator/stream/module names
Posted by Yogi Devendra <yo...@apache.org>.
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 <tu...@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 <sa...@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" <ra...@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....@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
> > >
> >
> >
> >
>
Re: empty operator/stream/module names
Posted by Tushar Gosavi <tu...@datatorrent.com>.
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 <sa...@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" <ra...@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....@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
> >
>
>
>
Re: empty operator/stream/module names
Posted by Vlad Rozov <v....@datatorrent.com>.
Names are already validated for uniqueness. I believe we still allow
names that are not fully compatible with the REST API, but otherwise all
unique names are considered to be valid.
Vlad
On 8/4/16 10:44, Sanjay Pujare wrote:
> That\u2019s a good point. System generated names can still be made to work for this use-case but I see the reason for having a name.
>
> But then another set of questions come up: we need to validate the name for uniqueness within an app, valid syntax etc. May be it\u2019s already being done.
>
> On 8/4/16, 10:36 AM, "Munagala Ramanath" <ra...@datatorrent.com> wrote:
>
> It will not be possible to configure such operators from an XML file other
> than through
> wildcards -- but maybe that's OK.
>
> Ram
>
> On Thu, Aug 4, 2016 at 10:03 AM, Sanjay Pujare <sa...@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\u2019t provide a name. I have some ideas.
> >
> >
> > On 8/4/16, 9:48 AM, "Munagala Ramanath" <ra...@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....@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
> > >
> >
> >
> >
> >
>
>
>
Re: empty operator/stream/module names
Posted by Amol Kekre <am...@datatorrent.com>.
I am not suggesting no names, AM should allocate system generated names and
they will then show up. It should even log it.
Thks
Amol
On Thu, Aug 4, 2016 at 10:44 AM, Sanjay Pujare <sa...@datatorrent.com>
wrote:
> That’s a good point. System generated names can still be made to work for
> this use-case but I see the reason for having a name.
>
> But then another set of questions come up: we need to validate the name
> for uniqueness within an app, valid syntax etc. May be it’s already being
> done.
>
> On 8/4/16, 10:36 AM, "Munagala Ramanath" <ra...@datatorrent.com> wrote:
>
> It will not be possible to configure such operators from an XML file
> other
> than through
> wildcards -- but maybe that's OK.
>
> Ram
>
> On Thu, Aug 4, 2016 at 10:03 AM, 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" <ra...@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
> > >
> >
> >
> >
> >
>
>
>
>
Re: empty operator/stream/module names
Posted by Sanjay Pujare <sa...@datatorrent.com>.
That’s a good point. System generated names can still be made to work for this use-case but I see the reason for having a name.
But then another set of questions come up: we need to validate the name for uniqueness within an app, valid syntax etc. May be it’s already being done.
On 8/4/16, 10:36 AM, "Munagala Ramanath" <ra...@datatorrent.com> wrote:
It will not be possible to configure such operators from an XML file other
than through
wildcards -- but maybe that's OK.
Ram
On Thu, Aug 4, 2016 at 10:03 AM, Sanjay Pujare <sa...@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" <ra...@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....@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
> >
>
>
>
>
Re: empty operator/stream/module names
Posted by Munagala Ramanath <ra...@datatorrent.com>.
It will not be possible to configure such operators from an XML file other
than through
wildcards -- but maybe that's OK.
Ram
On Thu, Aug 4, 2016 at 10:03 AM, Sanjay Pujare <sa...@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" <ra...@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....@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
> >
>
>
>
>
Re: empty operator/stream/module names
Posted by Munagala Ramanath <ra...@datatorrent.com>.
A couple of minor issues with empty names:
It will not be possible to configure such operators from an XML file other
than through
wildcards.
Also, the AM log messages will not be as informative with an empty name,
e.g.
2016-08-02 10:04:24,294 INFO com.datatorrent.stram.ResourceRequestHandler:
Strict anti-affinity = [] for container with operators
PTOperator[id=3,name=JdbcOutput]
Ram
On Thu, Aug 4, 2016 at 10:03 AM, Sanjay Pujare <sa...@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" <ra...@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....@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
> >
>
>
>
>
Re: empty operator/stream/module names
Posted by Sanjay Pujare <sa...@datatorrent.com>.
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" <ra...@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....@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
>
Re: empty operator/stream/module names
Posted by Munagala Ramanath <ra...@datatorrent.com>.
I don't see any reason to allow either.
Ram
On Thu, Aug 4, 2016 at 8:51 AM, Vlad Rozov <v....@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
>