[jira] [Created] (CALCITE-4108) ClassCastException: java.lang.Float cannot be cast to java.lang.Double
Roman Churganov created CALCITE-4108:
Summary: ClassCastException: java.lang.Float cannot be cast to
java.lang.Double
Key: CALCITE-4108
URL: https://issues.apache.org/jira/browse/CALCITE-4108
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.23.0
Environment: JDK 1.8
Reporter: Roman Churganov
running a query like :
{{select tp.o, MAX( tp.n )}}
{{ from tp join o on tp.o = o.k}}
{{ group by tp.o}}
{{type of }}{{tp.n in Schema is FLOAT, value of }}{{tp.n }}{{returned from
table is of type java.lang.Float, }}Calcite makes grouping internally and get
error
java.lang.ClassCastException: java.lang.Float cannot be cast to
java.lang.Doublejava.lang.ClassCastException: java.lang.Float cannot be cast to
java.lang.Double at Baz$1.apply(Unknown Source) at Baz$1.apply(Unknown Source)
at Baz$1.apply(Unknown Source) at
org.apache.calcite.adapter.enumerable.SequencedAdderAggregateLambdaFactory$AccumulatorAdderSeq.apply(SequencedAdderAggregateLambdaFactory.java:81)
at
org.apache.calcite.linq4j.EnumerableDefaults.groupBy_(EnumerableDefaults.java:806)
at
org.apache.calcite.linq4j.EnumerableDefaults.groupBy(EnumerableDefaults.java:739)
at
org.apache.calcite.linq4j.DefaultEnumerable.groupBy(DefaultEnumerable.java:299)
at Baz.bind(Unknown Source)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [VOTE] Release apache-calcite-avatica-go-5.0.0 (release candidate 0)
Hey everyone, Just a quick reminder that the vote for Avatica Go 5.0.0 is still open. Francis On 2/07/2020 8:17 pm, Stamatis Zampetakis wrote: Hey guys, it's been almost nine days from the start of the vote. Francis is putting a lot of effort in getting this release out so it would be nice if we could some more votes rather soon. Best, Stamatis On Sun, Jun 28, 2020 at 2:26 PM Stamatis Zampetakis wrote: Docker version 19.03.11, docker-compose version 1.25.5, build 8a1c60f6 * Checked signatures and checksums OK * Went over release note (Nice to see new contributors) OK * Checkout from git tag and run tests (docker-compose run test) OK * Download source artifacts and run tests (docker-compose run test) OK * Checked diff between repo and artifacts OK +1 (binding) Best, Stamatis On Sun, Jun 28, 2020 at 10:38 AM Francis Chuang wrote: Hey everyone, Just a quick reminder that the vote for Avatica Go 5.0.0 is still open. Francis On 23/06/2020 1:30 pm, Francis Chuang wrote: Hi all, I have created a release for Apache Calcite Avatica Go 5.0.0, release candidate 0. Thanks to everyone who has contributed to this release. The release notes are available here: https://github.com/apache/calcite-avatica-go/blob/0e3f5df582a09ac90869611b2d0a64b9f9b566e2/site/_docs/go_history.md The commit to be voted on: https://gitbox.apache.org/repos/asf?p=calcite-avatica-go.git;a=commit;h=0e3f5df582a09ac90869611b2d0a64b9f9b566e2 The hash is 0e3f5df582a09ac90869611b2d0a64b9f9b566e2 The artifacts to be voted on are located here: https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-go-5.0.0-rc0/ The hashes of the artifacts are as follows: src.tar.gz C49DB10E 5CC08815 2EEFFC83 7DD339DF 3327125E DCBA5DA3 9C9E74E1 F277D554 34DBE407 5436849A A4124661 4527A769 80EA7334 8ABDB2FE 56AA5B20 4FDFA43D Release artifacts are signed with the following key: https://people.apache.org/keys/committer/francischuang.asc Instructions for running the test suite is located here: https://github.com/apache/calcite-avatica-go/blob/0e3f5df582a09ac90869611b2d0a64b9f9b566e2/site/develop/avatica-go.md#testing Please vote on releasing this package as Apache Calcite Avatica Go 5.0.0. To run the tests without a Go environment, install docker and docker-compose. Then, in the root of the release's directory, run: docker-compose run test When the test suite completes, run "docker-compose down" to remove and shutdown all the containers. The vote is open for the next 72 hours and passes if a majority of at least three +1 PMC votes are cast. [ ] +1 Release this package as Apache Calcite Avatica Go 5.0.0 [ ] 0 I don't feel strongly about it, but I'm okay with the release [ ] -1 Do not release this package because... Here is my vote: +1 (binding) Francis
Re: Re: [DISCUSS] Refactor how planner rules are parameterized
If I am right, I am the release manager of 1.24.
I suggest releasing 1.24 a bit later(at the end of this month)
since 1.23 was released not long ago(on 2020.5.23).
Best,
Chunwei
On Fri, Jul 3, 2020 at 10:54 PM Michael Mior wrote:
> I'll just add for the relatively common case where a rule is matching
> a node with a specific node as a child, and so on that we could easily
> add a less verbose API to make this part of the rule definition
> equally concise.
>
> --
> Michael Mior
> mm...@apache.org
>
> Le dim. 14 juin 2020 à 15:36, Haisheng Yuan a écrit :
> >
> > Hi Julian,
> >
> > Thanks for working on this.
> >
> > We haven't reached a consensus yet.
> >
> > Frankly speaking, I agree with what Stamatis said earlier. Flexibility
> doesn't come with no cost. Admittedly, with this patch, any rule
> constructor refactoring won't need to deprecate old constructors and break
> backward compatibility, however, it also makes the rule definition much
> more verbose, less readable and understandable. IMHO, it does more harm
> than good.
> >
> > Let's see how CassandraFilterRule becomes before and after the change.
> >
> > Before this change:
> >
> > private static class CassandraFilterRule extends RelOptRule {
> > private static final CassandraFilterRule INSTANCE = new
> CassandraFilterRule();
> >
> > private CassandraFilterRule() {
> > super(operand(LogicalFilter.class,
> operand(CassandraTableScan.class, none())),
> > "CassandraFilterRule");
> > }
> > }
> >
> > After this change:
> >
> > private static class CassandraFilterRule
> > extends RelOptNewRule {
> > private static final CassandraFilterRule INSTANCE =
> > Config.EMPTY
> > .withOperandSupplier(b0 ->
> > b0.operand(LogicalFilter.class)
> > .oneInput(b1 -> b1.operand(CassandraTableScan.class)
> > .noInputs()))
> > .as(Config.class)
> > .toRule();
> >
> > /** Creates a CassandraFilterRule. */
> > protected CassandraFilterRule(Config config) {
> > super(config);
> > }
> >
> > /** Rule configuration. */
> > public interface Config extends RelOptNewRule.Config {
> > @Override default CassandraFilterRule toRule() {
> > return new CassandraFilterRule(this);
> > }
> > }
> > }
> >
> >
> > Intuitively, if we want to check what does the rule generally match or
> how it is defined, we just check the constructor. Now we checkout the
> constructor, only config is there, go to Config, there is still nothing
> interesting, we have to go to the INSTANCE. What is the difference with
> just using operand and optionConfig as the rule constructor?
> >
> >protected CassandraFilterRule(RelOptRuleOperand operand, Config
> config) {
> > super(operand, config);
> >}
> >
> > Or even simply replace Config with int, with each bit represent an
> option, if all of them are boolean options.
> >
> > Nothing is more flexible than just using RelOptRuleOperand as the
> parameter, just like the base class RelOptRule does. But do we want it?
> >
> > At the same time, with the new approach, it is now legit to create the
> following instance:
> >
> > private static final CassandraFilterRule INSTANCE2 =
> > Config.EMPTY
> > .withOperandSupplier(b0 ->
> > b0.operand(LogicalProject.class) // Even the is
> intended to match Filter, but it compiles
> > .oneInput(b1 -> b1.operand(CassandraTableScan.class)
> > .noInputs()))
> > .as(Config.class)
> > .toRule();
> >
> > Before we continue to the discussion and code review, we need to go back
> to the original problem, is it a real problem that is facing us? Is there
> any real demand or just artificial demand? How about we conduct a Calcite
> user survey to see how Calcite devs and users think? Then let's see how to
> move forward.
> >
> > [+1] Hell yeah, the new approach is awesome, let's go with it.
> > [+0] Meh, I am OK with current approach, I don't see any burden or
> problem with it.
> > [-1] Hell no, current approach is bad, the new one is even worse.
> >
> >
> > Thanks,
> > Haisheng
> >
> >
> > On 2020/06/12 23:51:56, Julian Hyde wrote:
> > > There is now a PR: https://github.com/apache/calcite/pull/2024. Can
> > > people please review?
> > >
> > > Here's the TL;DR:
> > >
> > > Previously, it was not easy to customize, re-use or extend planner
> > > rules. If you wished to customize a rule (i.e. create a new instance
> > > of a rule with different properties) you would have to call the rule's
> > > constructor. Frequently the required constructor did not exist, so we
> > > would have to add a new constructor and deprecate the old one.
> > >
> > > After this change, you start off from an instance of the rule, modify
> > > its configuration, and call toRule() on the configuration. (Rule
> > > constructors are now private,
[jira] [Created] (CALCITE-4107) Flink need result of method `allowsFraming` in `org.apache.calcite.sql.SqlRankFunction` to be true
JinxinTang created CALCITE-4107: --- Summary: Flink need result of method `allowsFraming` in `org.apache.calcite.sql.SqlRankFunction` to be true Key: CALCITE-4107 URL: https://issues.apache.org/jira/browse/CALCITE-4107 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.22.0 Reporter: JinxinTang stream sql in batch mode use this will occur `SQL validation failed. From line 1, column 106 to line 1, column 109: ROW/RANGE not allowed with RANK, DENSE_RANK or ROW_NUMBER functions` Reproduce code： CREATE TABLE src ( name STRING, age BIGINT ) WITH ( 'connector' = 'values' ) create view src_view as select *, ROW_NUMBER() OVER (PARTITION BY name ORDER BY age DESC) as row_num from src select name, age, row_num from src_view where row_num <= 3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
