Ok, thanks. I thought we deal with the ordinal mapping at a single place. If that s not the case, then I should definitely be the one to figure it out :)
Thanks for the hint, I will update the PR with the fix. On Wed, May 23, 2018 at 10:53 PM, Julian Hyde <[email protected]> wrote: > 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 > -- Regards, Atri l'apprenant
