I solved my problem just by capturing the original rowtype after sql parser.
Thanks
Enrico

Il ven 17 nov 2017, 22:44 Enrico Olivelli <eolive...@gmail.com> ha scritto:

>
>
> Il ven 17 nov 2017, 22:36 Julian Hyde <jh...@apache.org> ha scritto:
>
>> Translating to RelNode loses some metadata. When preparing a SQL
>> statement, we use the column names and types given to us by the
>> validator for use by ResultSetMetaData.
>>
>> There's a related interesting case where a column appears in ORDER BY
>> but not SELECT. For example, "SELECT x FROM t ORDER BY x, y". The
>> RelNode needs to have 2 columns but the ResultSet thinks it only has
>> one.
>>
>
> I am observing that Calcite tends to add support fields always at the
> 'right'. Is this a general behaviour or I am lucky and all the plans I am
> seeing behave this way ?
>
> I think I will try to capture field names from the SqlNodes, but this will
> be feasible if and only if the first N selected RelNodes of the physical
> plan represent the first N SqlNodes in the Select clause
>
> Enrico
>
>
>> Julian
>>
>>
>> On Fri, Nov 17, 2017 at 10:46 AM, Enrico Olivelli <eolive...@gmail.com>
>> wrote:
>> > Il ven 17 nov 2017, 19:19 Julian Hyde <jh...@apache.org> ha scritto:
>> >
>> >> > IMHO It would better to keep somethin like an EnumerableProjection
>> which
>> >> > renames the fields
>> >>
>> >> I disagree. If we commit to preserving field names all kinds of
>> >> optimization are not possible.
>> >>
>> >> In Calcite RelNode world, field names are a hint to make debugging
>> >> easier but are not ultimately reliable. The reliable way to reference
>> >> fields is by position.
>> >>
>> >
>> >
>> > I understand your point Julian. In my case I want the final resultset to
>> > have knowledge of the alias requested by the user.
>> >
>> > Select a as b from table
>> >
>> > ResultSet rs = ...
>> > String col = rs.getString("b");
>> > If I am losing the alias I can't support this case.
>> > The test case from Luis is working so there is some trick I am missing
>> >
>> > Enrico
>> >
>> >
>> >> Julian
>> >>
>> >>
>> >> On Fri, Nov 17, 2017 at 9:33 AM, Enrico Olivelli <eolive...@gmail.com>
>> >> wrote:
>> >> > I run the debugger on your test case.
>> >> > IMHO The BindableTableScan RelNode does not keep the original
>> aliases of
>> >> > the query.
>> >> > The test cases runs CalciteConnection, maybe there is some magic
>> during
>> >> the
>> >> > execution of the query.
>> >> > Can you provide me some insight ?
>> >> > Maybe it is better that I provide a reproducer.
>> >> > I am not using CalciteConnection but only the planner
>> >> >
>> >> > Thanks
>> >> > Enrico
>> >> >
>> >> > 2017-11-17 18:08 GMT+01:00 Enrico Olivelli <eolive...@gmail.com>:
>> >> >
>> >> >> your test is working
>> >> >>
>> >> >> I will try to understand where is the problem in my code
>> >> >>
>> >> >> b.q. I am looking for a sponsor for this patch, which is a real
>> blocker
>> >> >> for me, could you pleas take a look Luis ?
>> >> >> https://github.com/apache/calcite/pull/568
>> >> >>
>> >> >> Thank you
>> >> >> Enrico
>> >> >>
>> >> >> 2017-11-17 17:45 GMT+01:00 Luis Fernando Kauer <
>> >> >> lfka...@yahoo.com.br.invalid>:
>> >> >>
>> >> >>> Please insert the following test in ScannableTableTest and run:
>> >> >>>    /** ProjectableFilterableTable project push down using alias. */
>> >> >>>   @Test public void testPFPushDownWithAlias() throws Exception {
>> >> >>>     final StringBuilder buf = new StringBuilder();
>> >> >>>     final Table table = new BeatlesProjectableFilterableTable(buf,
>> >> true);
>> >> >>>     CalciteAssert.that()
>> >> >>>         .with(newSchema("s", "beatles", table))
>> >> >>>         .query("select \"i\" as theKey from \"s\".\"beatles\"")
>> >> >>>         .explainContains("EnumerableInterpreter\n"
>> >> >>>             + "  BindableTableScan(table=[[s, beatles]],
>> >> >>> projects=[[0]])\n")
>> >> >>>         .returnsUnordered("THEKEY=4",
>> >> >>>             "THEKEY=4",
>> >> >>>             "THEKEY=6",
>> >> >>>             "THEKEY=5");  }
>> >> >>> It passes for me.
>> >> >>> You'll need the updated version of this test class, because it was
>> >> >>> recently refactored.
>> >> >>> It's usually easier for other people to test the problem if you
>> create
>> >> >>> runnable test cases to show the problem.   Em sexta-feira, 17 de
>> >> novembro
>> >> >>> de 2017 14:29:09 BRST, Enrico Olivelli <eolive...@gmail.com>
>> escreveu:
>> >> >>>
>> >> >>>  In the RowType I have 'k1' and not "thekey"
>> >> >>>
>> >> >>> Enrico
>> >> >>>
>> >> >>> 2017-11-17 17:20 GMT+01:00 Luis Fernando Kauer
>> >> >>> <lfka...@yahoo.com.br.invalid
>> >> >>> >:
>> >> >>>
>> >> >>> >  Did you execute the query?
>> >> >>> > ProjectRemoveRule removes the Project when it is "trivial".
>> Since
>> >> the
>> >> >>> > only used project was pushed to BindableTableScan, the Project
>> would
>> >> >>> only
>> >> >>> > set the alias, but that can be done in row type.
>> >> >>> > The result is correct because RowType is preserved with the
>> alias.
>> >> It
>> >> >>> > just does not show in the plan.
>> >> >>> > However, I seems that repeating a column with different aliases
>> >> >>> generates
>> >> >>> > an error:
>> >> >>> > SELECT k1 theKey, k1 theKey2 FROM tblspace1.tsql where k1
>> ='mykey2'
>> >> >>> >
>> >> >>> > Regards,
>> >> >>> > Luis Fernando
>> >> >>> >
>> >> >>> >    Em sexta-feira, 17 de novembro de 2017 12:27:49 BRST, Enrico
>> >> >>> Olivelli <
>> >> >>> > eolive...@gmail.com> escreveu:
>> >> >>> >
>> >> >>> >  Hi,
>> >> >>> > I have a ProjectableFilterableTable, it seems to me that the
>> >> >>> BindablaScan
>> >> >>> > RelNode does not keep track of column name aliases in the
>> original
>> >> >>> > projection
>> >> >>> >
>> >> >>> > Example:
>> >> >>> >
>> >> >>> > Query:SELECT k1 theKey FROM tblspace1.tsql where k1 ='mykey2'
>> >> >>> >
>> >> >>> > -- Logical Plan
>> >> >>> > LogicalProject(THEKEY=[$0])
>> >> >>> >  LogicalFilter(condition=[=($0, 'mykey2')])
>> >> >>> >    EnumerableTableScan(table=[[tblspace1, tsql]])
>> >> >>> >
>> >> >>> > -- Best Plan
>> >> >>> > EnumerableInterpreter
>> >> >>> >  BindableTableScan(table=[[tblspace1, tsql]], filters=[[=($0,
>> >> >>> > 'mykey2')]],
>> >> >>> > projects=[[0]])
>> >> >>> >
>> >> >>> > Is this correct ?
>> >> >>> > IMHO It would better to keep somethin like an
>> EnumerableProjection
>> >> which
>> >> >>> > renames the fields
>> >> >>> >
>> >> >>> > Am I missing something ?
>> >> >>> > Thanks
>> >> >>> > Enrico
>> >> >>> >
>> >> >>> >
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >>
>> > --
>> >
>> >
>> > -- Enrico Olivelli
>>
> --
>
>
> -- Enrico Olivelli
>
-- 


-- Enrico Olivelli

Reply via email to