I am in favor of [2] as some operators can handle operations such as branching.
Thanks Sam > On May 29, 2020, at 9:00 AM, Jarek Potiuk <jarek.pot...@polidea.com> wrote: > > Hello everyone > > We had a discussion in Slack which turned out that we have yet another > opportunity to name the operators/hooks a bit more consistently. Seems that > we did not have any rule on how to name Transfer operators and we have > different conventions already. > > Explanation those are the two examples of conventions we have for transfer > operators: > > [1] *S3ToHiveOperator* > [2] *S3ToHiveTransferOperator* > [3] *S3ToHiveTransfer* > [4] We do not care about consistency > > Some initial comments that I gathered from the discussions:: > > - Why [1] and not [2,3]: "To" and "Transfer" seem a bit redundant > - Why [2] and not [1,3]: Longest, but most descriptive. It's easy to see > that it's an Operator, but you get the Transfer purpose as well. sometimes > when we use Acronyms (S3ToGCS :) ) it's hard to distinguish "To" from the > acronyms. > - Why [1, 2] and not [3]: All Operators (but not Sensor) end with "Operator" > - Why [3]: and not [1,2]: To introduce distinction: "Sensor", "Operator", > so maybe "Transfer" should be another "entity" and in the future, we might > implement a more generic Transfer approach > > I will let the discussion run till the end of today and cast a formal vote > afterwards > > I do not yet cancel Backport RC3, because I am not sure if this is > something we might want to do - maybe after discussion we decide we leave > the status quo. > > Discussion in slack here: > https://apache-airflow.slack.com/archives/CCPRP7943/p1590746507407100?thread_ts=1590742848.402600&cid=CCPRP7943 > > > J. > > > -- > > Jarek Potiuk > Polidea <https://www.polidea.com/> | Principal Software Engineer > > M: +48 660 796 129 <+48660796129> > [image: Polidea] <https://www.polidea.com/>
