(Moving the email thread onto the apache dev list, since optiq-dev is obsolete.)
It is probably fixed. We’ve made a number of improvements to how we generate bridge methods in lambdas (multiple versions of the apply method with arguments that are different sub-types of Object and sometimes primitive types). But it depends on a variety of factors, in particular whether sales.emps returns Object[], a synthetic class, or a user-defined class. To be sure, can you try this test case against the code base as of Oct 2013 (when the bug was logged)? If you can’t get that code base building easily, don’t sweat it. Julian On Jan 6, 2015, at 7:15 AM, Vladimir Sitnikov <[email protected]> wrote: > Hi, > > The issue was migrated to https://issues.apache.org/jira/browse/CALCITE-67 > As far as I understand the issue is fixed somehow as the following works in > current Calcite: > > @Test public void testGroupStarSalesEmps() { > CalciteAssert.that() > .with(CalciteAssert.Config.LINGUAL) > .query("select count(*) as c\n" > + "from sales.emps") > .returnsUnordered( > "C=2"); > } > > Vladimir > > -- > You received this message because you are subscribed to the Google Groups > "optiq-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout.
