No I can’t. Because then I would be fixing the bug. You can’t say you’re “blocked” and then ask that I tell you where in the code to fix it. Because to do that I have to stop what I am doing and start thinking about the problem you’re solving. In which case I might as well have fixed it myself.
Julian > On May 23, 2018, at 10:11 AM, Atri Sharma <[email protected]> wrote: > > Thanks. > > That seems to be the issue. Can you point me to where I need to fix > the mappings in order to ensure the right output please? > > Regards, > > Atri > > On Wed, May 23, 2018 at 10:39 PM, Julian Hyde <[email protected]> wrote: >> It’s definitely possible to re-order the inputs of EnumerableJoin for inner >> joins. For outer joins I’m not sure. It depends what the >> ExtendedEnumerable.join method is capable of. >> >> But remember that if you flip the inputs, the output columns will come out >> in a different order, and the column ordinals in the join condition will >> change. If you’re seeing errors due to columns not being the type you expect >> then you probably have the mappings mixed up. >> >> Julian >> >> >> >> >>> On May 22, 2018, at 7:59 PM, Atri Sharma <[email protected]> wrote: >>> >>> Please let me know. I am blocked on CALCITE - 500 on this, so it will >>> be great if I could get some advise here. >>> >>> Thanks >>> >>> On Tue, May 22, 2018 at 7:23 PM, Atri Sharma <[email protected]> wrote: >>>> I agree, however, the cast failures are something I am not sure about. If >>>> you look at the output bring generated, it is definitely incorrect . >>>> >>>> My main query is, is it possible to change the order of inputs to >>>> EnumerableJoin's implementation for a commutative join? If it is not, is >>>> there a reason why? >>>> >>>> Regards, >>>> >>>> Atri >>>> >>>> On Tue, 22 May 2018, 19:18 Michael Mior, <[email protected]> wrote: >>>>> >>>>> This doesn't surprise me since in general Calcite isn't expected to >>>>> preserve column names and I believe the tests rely on named columns in a >>>>> particular order. This doesn't seem to be a bug, but I can certainly see >>>>> how this would be considered unexpected behaviour. >>>>> >>>>> -- >>>>> Michael Mior >>>>> [email protected] >>>>> >>>>> >>>>> Le mar. 22 mai 2018 à 09:26, Atri Sharma <[email protected]> a écrit : >>>>> >>>>>> Hi All, >>>>>> >>>>>> As an experiment, I switched the order of inputs to >>>>>> EnumerableDefaults::join_ during the implementation stage of >>>>>> EnumerableJoin if the Join type is Inner. Since there will be no need >>>>>> to generate nulls on either side, I would assume that the choice of >>>>>> the side being built and the side being probed would not make a >>>>>> difference in the result. >>>>>> >>>>>> However, I see multiple test failures. On further investigation, I saw >>>>>> that the failures are coming due to change in order of the columns and >>>>>> due to the fact that a different column is being built now. For e.g., >>>>>> testInnerJoinValues fails with the following stack: >>>>>> >>>>>> Caused by: java.lang.NumberFormatException: For input string: "SameName" >>>>>> at >>>>>> >>>>>> java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) >>>>>> at java.base/java.lang.Integer.parseInt(Integer.java:652) >>>>>> at java.base/java.lang.Integer.parseInt(Integer.java:770) >>>>>> at org.apache.calcite.runtime.SqlFunctions.toInt(SqlFunctions.java:1571) >>>>>> at org.apache.calcite.runtime.SqlFunctions.toInt(SqlFunctions.java:1581) >>>>>> at Baz$4$1.moveNext(Unknown Source) >>>>>> at >>>>>> >>>>>> org.apache.calcite.linq4j.EnumerableDefaults.groupBy_(EnumerableDefaults.java:825) >>>>>> at >>>>>> >>>>>> org.apache.calcite.linq4j.EnumerableDefaults.groupBy(EnumerableDefaults.java:761) >>>>>> at >>>>>> >>>>>> org.apache.calcite.linq4j.DefaultEnumerable.groupBy(DefaultEnumerable.java:302) >>>>>> at Baz.bind(Unknown Source) >>>>>> at >>>>>> >>>>>> org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:365) >>>>>> at >>>>>> >>>>>> org.apache.calcite.jdbc.CalciteConnectionImpl.enumerable(CalciteConnectionImpl.java:301) >>>>>> at >>>>>> >>>>>> org.apache.calcite.jdbc.CalciteMetaImpl._createIterable(CalciteMetaImpl.java:559) >>>>>> at org.apache.calcite.jdbc.Calcite >>>>>> >>>>>> >>>>>> Can someone please advise? >>>>>> >>>>>> The current code is at: >>>>>> https://github.com/atris/calcite/tree/join_side_temp >>>>>> >>>>>> Regards, >>>>>> >>>>>> Atri >>>>>> >>> >>> >>> >>> -- >>> Regards, >>> >>> Atri >>> l'apprenant >> > > > > -- > Regards, > > Atri > l'apprenant
