You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@hive.apache.org by "Miklos Gergely (Jira)" <ji...@apache.org> on 2019/11/21 19:15:00 UTC

[jira] [Assigned] (HIVE-22525) Refactor HiveOpConverter

     [ https://issues.apache.org/jira/browse/HIVE-22525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miklos Gergely reassigned HIVE-22525:
-------------------------------------


> Refactor HiveOpConverter
> ------------------------
>
>                 Key: HIVE-22525
>                 URL: https://issues.apache.org/jira/browse/HIVE-22525
>             Project: Hive
>          Issue Type: Improvement
>          Components: Hive
>            Reporter: Miklos Gergely
>            Assignee: Miklos Gergely
>            Priority: Major
>             Fix For: 4.0.0
>
>
> HiveOpConverter is on it's way to become a monster class. It is already ~1300 lines long, and expected to grow. It should be refactored, cut into multiple classes in a reasonable way. It is a natural way to do this is to create separate visitor classes for the different RelNodes, which are already handled in different functions within HiveOpConverter. That way HiveOpConverter can be the dispatcher among those visitor classes, while each of them are handling some specific work, potentially requesting sub nodes to be dispatched by HiveOpConverter. The functions used by multiple visitors should be put into some utility class.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)