[CALCITE-419] Naming convention for planner rules

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 1.0.0-incubating
• Assignee: Julian Hyde
• Reporter: Julian Hyde
• Created: 20/Sep/14 18:45
• Updated: 08/Feb/15 08:56
• Resolved: 14/Nov/14 21:56

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

Issue Links

• is related to: CALCITE-296 Re-organize package structure