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 <[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
>
