Hi Julian, After fixing the compilation error, I ran into some runtime problems with CalciteTest, basically all caused by attempt to cast an EmptyCompositeTrait object to RelMultipleTrait while applying rules (either ProjectRemoveRule or PhoenixFilterRule). Guess we missed some handling of traits in our rule implementation. Could you please help me look at the issue? I have attached the diff file against Phoenix calcite branch.
We got our first join query to run last week (based on calcite 1.0.0), but I have a few questions regarding the implementation: 1. Added PhoenixJoinRule, but noticed that PhoenixSortRule did something different with the traits than other rules. What is that for? Should I also add something special for traits in PhoenixJoinRule? And generally I would like to know more about traits. Like what kind of traits do we usually have? And how are we supposed to implement a trait that indicates the ordering of an input (like for table scan, the result comes out ordered by primary key)? 2. splitJoinCondition() only regards lhs.column1 == rhs.column2 as equi conditions. Is there any other class/method available to recognize equi conditions of (any LHS expression/function) == (any RHS expression/function), for example "lhs.column1 + 3 = rhs.column2"? Or I write my own class? 3. Also added PhoenixProjectScanMergeRule, which pushes project into a PhoenixTableScan. Fixed an error caused by mismatch of rowtype by simply replacing the new PhoenixTableScan's rowtype with that of the original PhoenixProject. Does that look ok? Thanks, Maryann
