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