Yes, CALCITE-582 is fixed. It says so in the commit log, the release notes and the RC3 vote email.
Re Jacques’ comments: I have not marked it fixed because I have not merged it to master yet. When incorporating Vladimir’s patch I had to make some other changes to make ScannableTableTest.testSimple pass. I have not had chance to look at CALCITE-580 yet. I do not think it is fixed, and I do not consider it a show-stopper for the release. Julian Chin Wei Low is running into a different issue, probably On Feb 1, 2015, at 7:05 PM, Jacques Nadeau <[email protected]> wrote: > I'm actually a bit confused on this. The branch-1.0 shows that CALCITE-582 > was merged but I don't see it marked resolved nor a +1. It also looks like > Vladimir was the author but he doesn't like the fix. > > On Sun, Feb 1, 2015 at 5:33 PM, Chin Wei Low <[email protected]> wrote: > >> Hi, >> >> Did issue 582 fixed? >> >> Testing with query like this: select a from abc >> But, it throw the exception. >> Exception in thread "main" java.lang.ClassCastException: >> [Ljava.lang.Object; incompatible with java.lang.Integer >> at >> >> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:460) >> at >> >> org.apache.calcite.avatica.AvaticaResultSet.getInt(AvaticaResultSet.java:311) >> >> On Mon, Feb 2, 2015 at 12:37 AM, Vladimir Sitnikov < >> [email protected]> wrote: >> >>>> I needed to fix the bug and get a release out with the minimum >>> of disruption >>> >>> I see, however I raised the question since this area clearly is >>> related to public API. >>> I do not like "just fix the bug" approach without agreed APIs. >>> >>>> CALCITE-558. Please get involved >>> >>> Well, I try to block/prevent one more non-required convention to appear. >>> >>> Vladimir >>> >>
