Hello,
Local Calcite build with tests enabled on Linux: *OK*
Calcite-based system (Zoomdata) test suite: *OK*
Vote:
+1 (non-binding)
On Mon, Aug 10, 2020 at 11:09 AM Ruben Q L wrote:
> +1 (non binding)
> - Local Calcite build with tests (Windows10 + JDK8): OK
> - Calcite-based application
Hello,
Please add me as a contributor in Jira: username "anha".
--
Best regards,
Anton.
Anton Haidai created CALCITE-4150:
-
Summary: RelToSqlConverter does not support null without a cast:
"Unsupported type when convertTypeToSpec: NULL"
Key: CALCITE-4150
URL: https://issues.apache.org/j
Anton Haidai created CALCITE-4029:
-
Summary: ProjectRemoveRule auto pruning may prevent rules from
running if mixed conventions are used in a logical plan
Key: CALCITE-4029
URL: https://issues.apache.org/jira
Hello,
Local Calcite build with tests enabled on Linux: *OK*
Calcite-based system (Zoomdata) test suite: *OK*
Vote:
+1 (non-binding)
On Sat, May 16, 2020 at 7:02 AM Haisheng Yuan wrote:
> Hi all,
>
> I have created a build for Apache Calcite 1.23.0, release
> candidate 1.
>
> Thanks to
Hello,
Local Calcite build with tests enabled on Linux: *OK*
Calcite-based system (Zoomdata) test suite: *OK*
Vote:
+1 (non-binding)
On Tue, May 12, 2020 at 8:59 AM Haisheng Yuan wrote:
> Hi all,
>
> I have created a build for Apache Calcite 1.23.0, release
> candidate 0.
>
> Thanks to
While it is not a part of our daily CI, we are taking measures to detect
Calcite's regressions early, including several preliminary integrations
with Calcite's master between Calcite's releases.
Let me once again highlight that this unfortunate situation with the late
detection of CALCITE-3839
Sorry for reporting the bug too late, but the test that detected it was
related to a new feature of our system finalized just days ago so the right
test was not there when I voted on RC1.
On Mon, 2 Mar 2020 at 21:13, Vladimir Sitnikov
wrote:
> Julian>Can we keep it consistent please?
>
> It's
Hello,
Local Calcite build with tests enabled on Linux: *OK*
Calcite-based system (Zoomdata) test suite: *FAIL*
Our test suite detected a regression. It is easily reproducible in a unit
test. This test works fine in 1.21 branch.
https://issues.apache.org/jira/browse/CALCITE-3839
Vote:
0
Anton Haidai created CALCITE-3839:
-
Summary: Can't get group field by name: "field [ENAME] not found;"
Key: CALCITE-3839
URL: https://issues.apache.org/jira/browse/CALCITE-3839
Projec
Hello,
Local Calcite build with tests enabled on Linux: *OK*
Calcite-based system (Zoomdata) test suite: *OK**
***FYI: *EnumerableTableScanRule* changes related to CALCITE-3769 caused a
massive regression on our test suite because the rule produced
*BindableTableScan* instead of
Anton Haidai created CALCITE-3675:
-
Summary: SQL to Rel conversion is broken for coalesce on nullable
field
Key: CALCITE-3675
URL: https://issues.apache.org/jira/browse/CALCITE-3675
Project: Calcite
Anton Haidai created CALCITE-3537:
-
Summary: Can't apply materialized view with a simple filter
Key: CALCITE-3537
URL: https://issues.apache.org/jira/browse/CALCITE-3537
Project: Calcite
Anton Haidai created CALCITE-3364:
-
Summary: Can't group table function result due to a type cast error
Key: CALCITE-3364
URL: https://issues.apache.org/jira/browse/CALCITE-3364
Project: Calcite
Anton Haidai created CALCITE-3354:
-
Summary: RelToSqlConverter does not support
LogicalTableFunctionScan
Key: CALCITE-3354
URL: https://issues.apache.org/jira/browse/CALCITE-3354
Project: Calcite
Hello,
Local Calcite build with tests enabled on Linux: OK
Calcite-based system (Zoomdata) test suite: OK
+1 (non-binding)
On Fri, Sep 6, 2019 at 7:42 PM Stamatis Zampetakis
wrote:
> Hi all,
>
> I have created a build for Apache Calcite 1.21.0, release candidate 1.
>
> Thanks to everyone who
Hello,
Let me join the vote as far as my Calcite-base project
https://www.zoomdata.com/ has an extensive test suite that was able to
detect two major issues (CALCITE-3145, CALCITE-3162) in the previous 1.20
release (unfortunately, after the Calcite release itself during a
migration).
So here
ache.org/jira/browse/CALCITE-1515
> <https://issues.apache.org/jira/browse/CALCITE-1515>.
>
> Julian
>
>
> > On Jun 13, 2019, at 9:05 AM, Anton Haidai wrote:
> >
> > Hello,
> > Every Table Function usage example I was able to find is SQL-based,
>
Hello,
Every Table Function usage example I was able to find is SQL-based,
something like:
select * from table("s"."GenerateStrings"(5)) as t(n, c)
Could you please provide an example of Table Function scan that is
based on RelBuilder instead of SQL?
--
Best regards,
Anton.
As it turned out, a combination on "where 1=2" and
"FilterReduceExpressionsRule" works fine for my purposes, a code
sample could be found in the ticket description:
https://issues.apache.org/jira/browse/CALCITE-3076
On Fri, May 17, 2019 at 6:05 PM Anton Haidai wrote:
>
Anton Haidai created CALCITE-3076:
-
Summary: Error when AggregateJoinTransposeRule is used on empty
LogicalValues
Key: CALCITE-3076
URL: https://issues.apache.org/jira/browse/CALCITE-3076
Project
Hello,
I'm trying to reproduce a tricky bug in RelOptRulesTest. It requires
an empty LogicalValues with a desired row type to be a direct input of
a join. I can achieve the desired structure using RelBuilder and
LogicalValues.createEmpty(), however, I can't reproduce it in test's
SQL. For example,
Stamatis Zampetakis proposed a working solution (using
JoinProjectTransposeRule, see comments for details), so ticket is
closed now. Thanks!
On Wed, May 15, 2019 at 5:20 PM Anton Haidai wrote:
>
> Hello,
> There is an old ticket regarding Join structure unreachable b
Hello,
There is an old ticket regarding Join structure unreachable by default
JoinPushThroughJoinRule:
https://issues.apache.org/jira/browse/CALCITE-2666
This ticket contains some assumptions regarding the cause of the
issue, please see the text description and the image attachment.
So I have a
Anton Haidai created CALCITE-3060:
-
Summary: Materialized view: "target out of range" error
Key: CALCITE-3060
URL: https://issues.apache.org/jira/browse/CALCITE-3060
Project: Calcite
Anton Haidai created CALCITE-3052:
-
Summary: Error while applying rule
MaterializedViewAggregateRule(Project-Aggregate): ArrayIndexOutOfBoundsException
Key: CALCITE-3052
URL: https://issues.apache.org/jira/browse
ow you can obtain the equivalent in relational
> >algebra:
> >https://github.com/apache/calcite/blob/8eb852039db04c132ae7a99943495f87cf39dfd2/core/src/main/java/org/apache/calcite/sql2rel/StandardConvertletTable.java#L1437
> >
> >Best,
> >Stamatis
> >
> >
Builder().makeFlag(TimeUnitRange.MONTH),
>
> relBuilder.literal(1),
>
> relBuilder.getRexBuilder().makeDateLiteral(new DateString(2019, 1, 1))
>
> );
>
>
>
>
>
> Best,
> Hongze
>
>
>
>
>
> At 2019-02-22 19:16:09, "Anton Haidai&quo
Hello. In SQL, I can execute a query like "SELECT TIMESTAMPADD(month,
1, "date" ) FROM ..." and it works. But my attempts to do the same
thing using RelBuilder are not successful, for example, this code does
not work:
RexNode shiftedDateField = relBuilder.call(
According to my testing, some join configurations are unreachable by
default rules, here is a bug about it with a possible cause suggestion:
https://issues.apache.org/jira/browse/CALCITE-2666
On Tue, Nov 20, 2018 at 8:07 AM Wang, Ken
wrote:
> Hi, Julian
>
> I’m reading Apache Calcite source
Anton Haidai created CALCITE-2666:
-
Summary: JoinPushThroughJoinRule can't reach an optimal plan in
some 3+ joins cases
Key: CALCITE-2666
URL: https://issues.apache.org/jira/browse/CALCITE-2666
Hello,
here is a small utility that gives an ability to view a visual
representation of Calcite traces: Rels, Subsets, Sets, so it is possible to
explore not only the best plan, but also dead end options generated by
Rules during planning.
Here is the link to the application:
Hello!
I have the following problem. Sample SQL input is the following:
SELECT *
FROM X
INNER JOIN A
ON X.id = A.id
INNER JOIN X2
ON X.id = X2.id
INNER JOIN X3
ON X.id = X3.id
According to a custom cost model used, it would beneficial to move the
select from the table "A" as high as possible in
Hello!
I have the following problem. Sample SQL input is the following:
SELECT *
FROM X
INNER JOIN A
ON X.id = A.id
INNER JOIN X2
ON X.id = X2.id
INNER JOIN X3
ON X.id = X3.id
According to a custom cost model used, it would beneficial to move select
from the table "A" as high as possible in
Anton Haidai created CALCITE-2618:
-
Summary: It is not possible to execute IN on Enumerable: "cannot
translate call IN"
Key: CALCITE-2618
URL: https://issues.apache.org/jira/browse/CA
Anton Haidai created CALCITE-2616:
-
Summary: Can't create Unicode literal by RelBuilder
Key: CALCITE-2616
URL: https://issues.apache.org/jira/browse/CALCITE-2616
Project: Calcite
Issue Type
36 matches
Mail list logo
