+1 If module is intended to be a superset of operator, then it should be usable like an operator for the configuration aspect also.
On Mon, Oct 12, 2015 at 12:50 PM, Vlad Rozov <[email protected]> wrote: > I think that we should try make modules interchangeable with operators as > much as possible, so that applications (the same applies to modules) > designer can replace a module with a functional equivalent operator or > replace an operator with a functional equivalent module. In certain context > modules should behave like operators and be indistinguishable from > operators. Taking this into account, I think that using a module and an > operator with the same name within DAG namespace should not be allowed. It > still should be possible to have an operator in the DAG with the same name > as another operator added to a module belonging to the DAG as module's DAG > has its own namespace. > > Thank you, > > Vlad > > > On 10/12/15 12:30, Timothy Farkas wrote: > >> I think using the module keyword in configurations helps to reduce >> confusing corner cases. There are four cases/things I don't like about >> using the operator keyword for both operators and modules: >> >> 1. A module with the same name as one of its internal operators >> 2. A module with the same name as another operator in the dag. >> 3. When there are module specific attributes, things could get >> unnecessarily messy in the configuration handling code >> 4. Confusing the user by giving them the impression that modules and >> operators are the same thing when they're not. >> >> Thanks, >> Tim >> >> On Mon, Oct 12, 2015 at 10:08 AM, Tushar Gosavi <[email protected]> >> wrote: >> >> I was thinking from more of the view that module and operator can share a >>> same name in the DAG. In this case it is necessary to distinguish between >>> operator and module. If we don't want this behavior, and if its ok to use >>> operator keyword to set module property then we can treat them as >>> operators >>> while setting properties, In fact, I think by doing this we could reuse >>> property setting code for operator. >>> >>> - Tushar. >>> >>> >>> On Mon, Oct 12, 2015 at 9:52 PM, Vlad Rozov <[email protected]> >>> wrote: >>> >>> Is it necessary to distinguish modules from operators when setting >>>> >>> modules >>> >>>> properties? Unless it is necessary to set module internal operator >>>> properties it may be better to treat modules the same way as operators. >>>> >>>> Thank you, >>>> >>>> Vlad >>>> >>>> >>>> On 10/12/15 04:40, Tushar Gosavi wrote: >>>> >>>> Hi All, >>>>> >>>>> As part of module support we will allow specifying module properties >>>>> through >>>>> external configuration files. The format will be similar to the >>>>> >>>> operator, >>> >>>> instead of operator keyword we will use module keyword for properties >>>>> on module. >>>>> >>>>> >>>>> dt.application.<appname>.module.<modulename>.prop.<propertyname>=<value> >>>>> dt.application.<appname>.module.<modulename>.<propertyname>=<value> >>>>> dt.module.<modulename>.prop.<propertyname>=<value> >>>>> dt.module.<modulename>.<propertyname>=<value> >>>>> >>>>> >>>>> Setting attribute on the module. >>>>> dt.application.<appname>.module.<modulename>.attr.<moduleattr>=<value> >>>>> dt.module.<modulename>.attr.<moduleattr>=<value> >>>>> >>>>> There are no module attributes defined now, but we will add them in >>>>> >>>> future >>> >>>> like >>>>> whether to group operators during parallel partitioning. >>>>> >>>>> Setting attribute on a module port. >>>>> dt.module.<modulename>.port.<portname>.attr.<attributename> >>>>> >>>>> The port attributes will be transferred to the internal operator port >>>>> where >>>>> it is >>>>> mapped to. >>>>> >>>>> Please let us know, If we are missing something, or some syntax need >>>>> changes. >>>>> >>>>> Regards, >>>>> - Tushar. >>>>> >>>>> >>>>> >
