Hi All, Following are the choices for separator Char Votes / 3 $ 3 :: 3 ~ 1 # 1
I will '/' as a separator as it will look like as a hierarchical path in REST api, but need to confirm that as web framework might not support '/' character in parameter. If there is any issue while processing REST calls, I will use '$' as a separator. -Tushar. On Wed, Dec 2, 2015 at 6:04 PM, Tushar Gosavi <[email protected]> wrote: > We already have explicit check to guard against duplicate operator names. > > On Tue, Dec 1, 2015 at 3:41 PM, 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. >> > >
