+1 for "/". It may help with REST API (no need to worry about "/" in the
operator/module name).
Thank you,
Vlad
On 12/1/15 08:03, Amol Kekre wrote:
This char will also be in rest API from stram. So we will need to look at URL
sensitivity.
Amol
Sent from my iPhone
On Dec 1, 2015, at 2:11 AM, "Ganelin, Ilya" <[email protected]> wrote:
Regardless of which symbol we select, we should add an explicit run-time check
to guard against collisions.
Thank you,
Ilya Ganelin
-----Original Message-----
From: Priyanka Gugale
[[email protected]<mailto:[email protected]>]
Sent: Tuesday, December 01, 2015 04:01 AM Eastern Standard Time
To: [email protected]
Subject: Re: [APEX-3/APEX-104] Module Separator.
+1 for $.
-Priyanka
On Tue, Dec 1, 2015 at 2:26 PM, Chandni Singh <[email protected]>
wrote:
I will also consider tilde as a separator. Module1~Operator1.
Less conflict and more readable.
On Tue, Dec 1, 2015 at 12:22 AM, Shubham Pathak <[email protected]>
wrote:
+1 for $ or (::) double colon
Thanks,
Shubham
On Tue, Dec 1, 2015 at 11:11 AM, Chinmay Kolhatkar <
[email protected]>
wrote:
Hi,
I want to propose 2 more options for this:
1) $ (Dollar delimited)
Dollar sign is usually to indicate inner classes in Java. Considering
that
I believe this can work in REST APIs and CLI as well.
Hence the operator inside module can look like:
Module1*$*Module2*$*Operator1
2) | (Pipe Delimited)
Operator name would look like:
Module1*|*Module2*|*Operator1
3) / (Unix File Seperator)
This seperate is common and used in most of the places. file seperator
is
also used to indicate the content inside something.
Operator name would look like:
Module1*/*Module2*/*Operator1
If there are technical challenges in above, I would vote for (::)
double
colon.
-Chinmay.
~ Chinmay.
On Tue, Dec 1, 2015 at 11:01 AM, Tushar Gosavi <[email protected]
wrote:
dot can not be used in dt-site.xml, as '.' is used as separator for
parsing
various component from configuration file.
- Tushar.
On Tue, Dec 1, 2015 at 10:48 AM, Yogi Devendra <
[email protected]>
wrote:
I would prefer '.' (dot).
If there are some technical challenges for dot then I vote for :
(colon)
or
:: (double colon) in that sequence.
~ Yogi
On 1 December 2015 at 10:17, Gaurav Gupta <[email protected]>
wrote:
What about using “#”? We use this for Unifiers.
Thanks
- Gaurav
On Nov 30, 2015, at 8:08 PM, Tushar Gosavi <
[email protected]
wrote:
Hi All,
As part of module support, we will need to generate names for
operators
internal to the module before adding it to the original DAG to
avoid
conflict of names. For example if a developer adds a operator
with
name
"A"
and module is name "M" in the DAG. Developer of 'M' is adding a
operator
'A' into the module DAG. To avoid name conflict
with the operator in the main DAG we will generate name for
internal
operators by concatenation of module name and operator name.
The
'A'
within
module 'M' will be added to main DAG as 'M_A'. This works for
recursive
modules too. (i.e module containing module).
Which separator should we use for module namespace? The
requirement
are
- Less chances of collision. (User can add operator with name
'M_A'
too).
- Compatible with json format. (Should not have a problem while
parsing
json response from rest api)
- Should be able to specify property in dt-site.xml.
While '_' works, In the pull request it has been pointed out
that
it
has
higher chance of collision. Few choices are
1) _ (Underscore)
2) __ (double underscore)
3) : (colon, I will check compatibility with rest API, as it is
used
to
separate key and value in json)
4) :: (Double colon).
5) Let developer choose the separator by specifying dag
property,
but
default is still needed.
6) Any other option?
Please suggest which approach to take?
Regards,
-Tushar.
________________________________________________________
The information contained in this e-mail is confidential and/or proprietary to
Capital One and/or its affiliates and may only be used solely in performance of
work or services for Capital One. The information transmitted herewith is
intended only for use by the individual or entity to which it is addressed. If
the reader of this message is not the intended recipient, you are hereby
notified that any review, retransmission, dissemination, distribution, copying
or other use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error, please
contact the sender and delete the material from your computer.
