[jira] [Created] (CALCITE-6341) DynamicRecordType join query will generate uncompailable code
Yonatan Graber created CALCITE-6341:
---
Summary: DynamicRecordType join query will generate uncompailable
code
Key: CALCITE-6341
URL: https://issues.apache.org/jira/browse/CALCITE-6341
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.36.0, 1.35.0, 1.34.0, 1.33.0, 1.32.0, 1.31.0, 1.30.0,
1.29.0, 1.28.0, 1.27.0, 1.26.0, 1.25.0, 1.24.0, 1.23.0
Reporter: Yonatan Graber
See full minimal reproduction in
[https://github.com/yonatang/calcite-join-issue/|https://github.com/yonatang/calcite-join-issue/tree/main]
—
When creating a table with {{DynamicRecordType}} rowType, a joined query will
generate a code that won't get compiled.
For example, with the relevant schema, this query:
{{SELECT d1.a ,d2.a FROM static_table d1 join static_table d2 on d1.a=d2.a}}
Will not execute, because the generated code will contain a Baz class with the
following Comparator class:
{code:java}
new java.util.Comparator(){
public int compare(Object v0, Object v1) {
final int c;
c =
org.apache.calcite.runtime.Utilities.compareNullsLastForMergeJoin((Comparable)
v0, (Comparable) v1);
if (c != 0) {
return c;
}
return 0;
}
public int compare(Object o0, Object o1) {
return this.compare(o0, o1);
}
} {code}
This fails because it has two {{int compare(Object o0, Object o1)}} methods.
Notice this issue was introduced at Calcite 1.23.0. The query will work as
expected in versions 1.22 and below.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6248) Illegal dates are accepted by casts
[
https://issues.apache.org/jira/browse/CALCITE-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830774#comment-17830774
]
Mihai Budiu commented on CALCITE-6248:
--
I thought we were ready to close this one, but the situation is more
complicated: strings representing dates and times can appear in multiple
places: as values for literals e.g., DATE '1945-1-1', as values in a VALUES
statement, which may be implicitly cast, and in casts e.g., CAST('1945-1-1' AS
DATE). And it seems that different validation rules are needed for different
contexts. It seems, for example, that casts should be more lenient than
literals in their checking.
There are several other related issues e.g., [CALCITE-5678], [CALCITE-5957]
I am afraid that this issue is not the last one in this chain. What is needed
is *two* versions of each validation function, one strict and one lenient, and
Calcite should use the appropriate function depending on the context.
> Illegal dates are accepted by casts
> ---
>
> Key: CALCITE-6248
> URL: https://issues.apache.org/jira/browse/CALCITE-6248
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following test passes in SqlOperatorTest:
> {code:java}
> @Test public void testIllegalDate() {
> final SqlOperatorFixture f = fixture();
> f.checkScalar("cast('1945-02-32' as DATE)",
> "1945-03-04", "DATE NOT NULL");
> }
> {code}
> There is no February 32, I suspect that this expression should produce an
> error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6340) RelBuilder always creates Project with Convention.NONE during aggregate_
Adam Kennedy created CALCITE-6340:
-
Summary: RelBuilder always creates Project with Convention.NONE
during aggregate_
Key: CALCITE-6340
URL: https://issues.apache.org/jira/browse/CALCITE-6340
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.36.0
Reporter: Adam Kennedy
In the RelBuilder method aggregate_, when (config.pruneInputOfAggregate() && r
instanceof Project) line 2443 the Project will be rewritten to remove unused
columns.
When this happens, the new Project will be created with the following line
{{{}2487: r =
{}}}{{{}2488: project.copy(cluster.traitSet(), project.getInput(),
newProjects,{}}}
{{2489: builder.build());}}
The use of cluster.traitSet() returns emptyTraitSet which is always going to
use Convention.NONE regardless of the Rebuilder's ProjectFactory.
In the case of a query plan using a non-Logical convention FOO, with FooProject
nodes that require the FOO convention, RelBuilder will normally happily produce
FooProject nodes with FOO convention, allowing many CoreRules to be easily
reused for custom Conventions.
However, while RelBuilder will produce FooProject with FOO convention in the
majority of cases, for the one specific case of column pruning a Project input
to an aggregate, it will instead product a FooProject with NONE convention.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6338) RelMdCollation#project can return an incomplete list of collations in the presence of aliasing
[
https://issues.apache.org/jira/browse/CALCITE-6338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L resolved CALCITE-6338.
Resolution: Fixed
Fixed via
[{{d5b6b5c}}|https://github.com/apache/calcite/commit/d5b6b5c01ff17cac100a591a4cc4c9e83d4e1ace]
> RelMdCollation#project can return an incomplete list of collations in the
> presence of aliasing
> --
>
> Key: CALCITE-6338
> URL: https://issues.apache.org/jira/browse/CALCITE-6338
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> {{RelMdCollation#project}} can return an incomplete list of collations.
> Let us say we have a Project (or a Calc) that projects the following
> expressions (notice that $2 will become $1 and $2 after the projection): $0,
> $2, $2, $3
> The Project's input has collation [2, 3]
> In order to calculate the Project's own collation, {{RelMdCollation#project}}
> will be called, and a MultiMap targets will be computed because, as in this
> case, a certain "source field" (e.g. 2) can have multiple project targets
> (e.g. 1 and 2). However, when the collation is being computed, *only the
> first target will be considered* (and the rest will be discarded):
> {code}
> public static @Nullable List project(RelMetadataQuery mq,
> RelNode input, List projects) {
> ...
> for (RelFieldCollation ifc : ic.getFieldCollations()) {
> final Collection integers = targets.get(ifc.getFieldIndex());
> if (integers.isEmpty()) {
> continue loop; // cannot do this collation
> }
> fieldCollations.add(ifc.withFieldIndex(integers.iterator().next()));
> // <-- HERE!!
> }
> {code}
> Because of this, the Project's collation will be [1 3], but there is also
> another valid one ([2 3]), so the correct (complete) result should be: [1 3]
> [2 3]
> This seems a minor problem, but it can be the root cause of more relevant
> issues. For instance, at the moment I have a scenario (not so easy to
> reproduce with a unit test) where a certain plan with a certain combination
> of rules in a HepPlanner results in a StackOverflow due to
> SortJoinTransposeRule being fired infinitely. The root cause is that, after
> the first application, the rule does not detect that the Join's left input is
> already sorted (due to the previous application of the rule), because there
> is a "problematic" Project on it (that shows the problem described above),
> which returns only one collation, whereas the second collation (the one being
> discarded) is the Sort's collation, so it would be one that would prevent the
> SortJoinTransposeRule from being re-applied over and over.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6339) Replace hashicorp/go-uuid with google/uuid
[ https://issues.apache.org/jira/browse/CALCITE-6339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang resolved CALCITE-6339. - Resolution: Fixed > Replace hashicorp/go-uuid with google/uuid > -- > > Key: CALCITE-6339 > URL: https://issues.apache.org/jira/browse/CALCITE-6339 > Project: Calcite > Issue Type: Task > Components: avatica-go >Reporter: Francis Chuang >Assignee: Francis Chuang >Priority: Minor > Fix For: avatica-go-5.4.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The hashicorp/uuid library generates strings that look like uuids but are > purely random. It is also not as popular or as active as the google/uuid > library. > The google/uuid library generates real uuids that are RFC compliant. The > library is also more popular and actively maintained. > These ids are used to generate connection ids, so whether they are RFC > compliant or not is inconsequential, however, it is a good idea to generate > compliant uuids if downstream users behind avatica expects correct and > compliant uuids. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6339) Replace hashicorp/go-uuid with google/uuid
Francis Chuang created CALCITE-6339: --- Summary: Replace hashicorp/go-uuid with google/uuid Key: CALCITE-6339 URL: https://issues.apache.org/jira/browse/CALCITE-6339 Project: Calcite Issue Type: Task Components: avatica-go Reporter: Francis Chuang Assignee: Francis Chuang Fix For: avatica-go-5.4.0 The hashicorp/uuid library generates strings that look like uuids but are purely random. It is also not as popular or as active as the google/uuid library. The google/uuid library generates real uuids that are RFC compliant. The library is also more popular and actively maintained. These ids are used to generate connection ids, so whether they are RFC compliant or not is inconsequential, however, it is a good idea to generate compliant uuids if downstream users behind avatica expects correct and compliant uuids. -- This message was sent by Atlassian Jira (v8.20.10#820010)
