[jira] [Updated] (OPTIQ-419) Naming convention for planner rules

["Julian Hyde (JIRA)" <ji...@apache.org>]

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

Julian Hyde updated OPTIQ-419:
------------------------------
    Description: 
I propose a new naming convention for planner rules. This change would rename existing rules.

The naming convention is advisory, not mandatory. Rule authors would not need to follow it if they don’t feel that it makes things clearer.

Discussion from the dev list:

As the number of rules grows, it becomes more difficult to find out whether a similar rule has already been added. The fact that there are several ways to name a rule adds to the confusion.

For instance, consider a rule that converts ‘join(project( x ), project( y ))’ into ‘project(join(x, y))’. The actual rule is called {{PullUpProjectsAboveJoinRule}} but it could equally be called {{PushJoinThroughProjectsRule}}.

There are lots of rules called {{PushXxxThroughYyyRule}}, too.

I propose the naming convention

   {{<Reltype1><Reltype2>[…]<Verb>Rule}}

where {{ReltypeN}} is the class of the Nth {{RelNode}} matched, in depth-first order, ignoring unimportant operands, and removing any ‘Rel’ suffix
Verb is what happens — typically Transpose, Swap, Merge, Optimize.

Thus:
* {{PullUpProjectsAboveJoinRule}} becomes {{JoinProjectTransposeRule}}
* {{PushAggregateThroughUnionRule}} becomes {{AggregateUnionTransposeRule}}
* {{MergeProjectRule}} becomes {{ProjectMergeRule}}
* {{MergeFilterOntoCalcRule}} becomes {{FilterCalcMergeRule}}
* {{EnumerableJoinRule}} remains {{EnumerableJoinRule}} (Or how about {{JoinAsEnumerableRule}}?)
* {{SwapJoinRule}} becomes {{JoinSwapInputsRule}}

  was:
I propose a new naming convention for planner rules. This change would rename existing rules.

The naming convention is advisory, not mandatory. Rule authors would not need to follow it if they don’t feel that it makes things clearer.

Discussion from the dev list:

As the number of rules grows, it becomes more difficult to find out whether a similar rule has already been added. The fact that there are several ways to name a rule adds to the confusion.

For instance, consider a rule that converts ‘join(project(x), project(y))’ into ‘project(join(x, y))’. The actual rule is called {{PullUpProjectsAboveJoinRule}} but it could equally be called {{PushJoinThroughProjectsRule}}.

There are lots of rules called {{PushXxxThroughYyyRule}}, too.

I propose the naming convention

   {{<Reltype1><Reltype2>[…]<Verb>Rule}}

where {{ReltypeN}} is the class of the Nth {{RelNode}} matched, in depth-first order, ignoring unimportant operands, and removing any ‘Rel’ suffix
Verb is what happens — typically Transpose, Swap, Merge, Optimize.

Thus:
* {{PullUpProjectsAboveJoinRule}} becomes {{JoinProjectTransposeRule}}
* {{PushAggregateThroughUnionRule}} becomes {{AggregateUnionTransposeRule}}
* {{MergeProjectRule}} becomes {{ProjectMergeRule}}
* {{MergeFilterOntoCalcRule}} becomes {{FilterCalcMergeRule}}
* {{EnumerableJoinRule}} remains {{EnumerableJoinRule}} (Or how about {{JoinAsEnumerableRule}}?)
* {{SwapJoinRule}} becomes {{JoinSwapInputsRule}}


> Naming convention for planner rules
> -----------------------------------
>
>                 Key: OPTIQ-419
>                 URL: https://issues.apache.org/jira/browse/OPTIQ-419
>             Project: Optiq
>          Issue Type: Bug
>            Reporter: Julian Hyde
>            Assignee: Julian Hyde
>
> I propose a new naming convention for planner rules. This change would rename existing rules.
> The naming convention is advisory, not mandatory. Rule authors would not need to follow it if they don’t feel that it makes things clearer.
> Discussion from the dev list:
> As the number of rules grows, it becomes more difficult to find out whether a similar rule has already been added. The fact that there are several ways to name a rule adds to the confusion.
> For instance, consider a rule that converts ‘join(project( x ), project( y ))’ into ‘project(join(x, y))’. The actual rule is called {{PullUpProjectsAboveJoinRule}} but it could equally be called {{PushJoinThroughProjectsRule}}.
> There are lots of rules called {{PushXxxThroughYyyRule}}, too.
> I propose the naming convention
>    {{<Reltype1><Reltype2>[…]<Verb>Rule}}
> where {{ReltypeN}} is the class of the Nth {{RelNode}} matched, in depth-first order, ignoring unimportant operands, and removing any ‘Rel’ suffix
> Verb is what happens — typically Transpose, Swap, Merge, Optimize.
> Thus:
> * {{PullUpProjectsAboveJoinRule}} becomes {{JoinProjectTransposeRule}}
> * {{PushAggregateThroughUnionRule}} becomes {{AggregateUnionTransposeRule}}
> * {{MergeProjectRule}} becomes {{ProjectMergeRule}}
> * {{MergeFilterOntoCalcRule}} becomes {{FilterCalcMergeRule}}
> * {{EnumerableJoinRule}} remains {{EnumerableJoinRule}} (Or how about {{JoinAsEnumerableRule}}?)
> * {{SwapJoinRule}} becomes {{JoinSwapInputsRule}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)