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
