[jira] [Created] (CALCITE-4698) Return type of timestampadd(..., ..., timestamp_ltz) should be timestamp_ltz instead of timestamp
Caizhi Weng created CALCITE-4698:
Summary: Return type of timestampadd(..., ..., timestamp_ltz)
should be timestamp_ltz instead of timestamp
Key: CALCITE-4698
URL: https://issues.apache.org/jira/browse/CALCITE-4698
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Caizhi Weng
Currently {{SqlTimestampAddFunction#deduceType}} does not deal with
timestamp_ltz type correctly. Return type of {{timestampadd(..., ...,
timestamp_ltz)}} will be timestamp but it should be timestamp_ltz.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4365) SEARCHes in ANDs and ORs cannot be simplified if the complexity of its SARG can actually be reduced to 1
Caizhi Weng created CALCITE-4365:
Summary: SEARCHes in ANDs and ORs cannot be simplified if the
complexity of its SARG can actually be reduced to 1
Key: CALCITE-4365
URL: https://issues.apache.org/jira/browse/CALCITE-4365
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Caizhi Weng
Consider the following test case in {{RexProgramTest}}.
{code:java}
@Test void testSimplifySearch() {
// (deptno <> 20 OR deptno IS NULL) AND deptno = 10
// ==>
// deptno = 10
final RexNode e =
and(
in(vInt(), literal(10), literal(20)),
eq(vInt(), literal(10)));
checkSimplify2(e, "=(?0.int0, 10)", "=(?0.int0, 10)");
}
{code}
We expect that {{AND(SEARCH(?0, [10, 20], =(?0, 10)))}} can be simplified to
{{=(?0, 10)}} but fails. This is because {{RexSimplify#simplifyAnd}} and
{{RexSimplify#simplifyOrs}} does not deal with the case when the complexity of
{{SargCollector}} is 1.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4351) The result of RelMdUtil#numDistinctVals will always be 0 when inputs are large
[
https://issues.apache.org/jira/browse/CALCITE-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caizhi Weng updated CALCITE-4351:
-
Summary: The result of RelMdUtil#numDistinctVals will always be 0 when
inputs are large (was: The result of RelMdUtil#numDistinctVals is incorrect
when inputs are large)
> The result of RelMdUtil#numDistinctVals will always be 0 when inputs are large
> --
>
> Key: CALCITE-4351
> URL: https://issues.apache.org/jira/browse/CALCITE-4351
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Caizhi Weng
>Priority: Major
>
> Previous implementation of {{RelMdUtil#numDistinctVals}} uses the
> approximation {{ln(1 + x) ~= x}} when {{x}} is small.
> However CALCITE-4132 remove this approximation to make the result more
> accurate. This causes the function to calculate an incorrect result for large
> inputs (for example, when {{domainSize = 1e18}} and {{numSelected = 1e10}}
> the result is 0) due to precision problems.
> What I would suggest is to treat small and large inputs in different ways.
> For small inputs we use the new, more precise function and for large inputs
> we use the old, approximated function.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4351) The result of RelMdUtil#numDistinctVals is incorrect when inputs are large
[
https://issues.apache.org/jira/browse/CALCITE-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caizhi Weng updated CALCITE-4351:
-
Description:
Previous implementation of {{RelMdUtil#numDistinctVals}} uses the approximation
{{ln(1 + x) ~= x}} when {{x}} is small.
However CALCITE-4132 remove this approximation to make the result more
accurate. This causes the function to calculate an incorrect result for large
inputs (for example, when {{domainSize = 1e18}} and {{numSelected = 1e10}} the
result is 0) due to precision problems.
What I would suggest is to treat small and large inputs in different ways. For
small inputs we use the new, more precise function and for large inputs we use
the old, approximated function.
was:
Previous implementation of {{RelMdUtil#numDistinctVals}} uses the approximation
{{ln(1 + x) ~= x}} when {{x}} is small.
However CALCITE-4132 remove this approximation to make the result more
accurate. This causes the function to calculate an incorrect result for large
inputs (for example, {{domainSize = 1e18}} and {{numSelected = 1e10}}) due to
precision problems.
What I would suggest is to treat small and large inputs in different ways. For
small inputs we use the new, more precise function and for large inputs we use
the old, approximated function.
> The result of RelMdUtil#numDistinctVals is incorrect when inputs are large
> --
>
> Key: CALCITE-4351
> URL: https://issues.apache.org/jira/browse/CALCITE-4351
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Caizhi Weng
>Priority: Major
>
> Previous implementation of {{RelMdUtil#numDistinctVals}} uses the
> approximation {{ln(1 + x) ~= x}} when {{x}} is small.
> However CALCITE-4132 remove this approximation to make the result more
> accurate. This causes the function to calculate an incorrect result for large
> inputs (for example, when {{domainSize = 1e18}} and {{numSelected = 1e10}}
> the result is 0) due to precision problems.
> What I would suggest is to treat small and large inputs in different ways.
> For small inputs we use the new, more precise function and for large inputs
> we use the old, approximated function.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4351) The result of RelMdUtil#numDistinctVals is incorrect when inputs are large
Caizhi Weng created CALCITE-4351:
Summary: The result of RelMdUtil#numDistinctVals is incorrect when
inputs are large
Key: CALCITE-4351
URL: https://issues.apache.org/jira/browse/CALCITE-4351
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.26.0
Reporter: Caizhi Weng
Previous implementation of {{RelMdUtil#numDistinctVals}} uses the approximation
{{ln(1 + x) ~= x}} when {{x}} is small.
However CALCITE-4132 remove this approximation to make the result more
accurate. This causes the function to calculate an incorrect result for large
inputs (for example, {{domainSize = 1e18}} and {{numSelected = 1e10}}) due to
precision problems.
What I would suggest is to treat small and large inputs in different ways. For
small inputs we use the new, more precise function and for large inputs we use
the old, approximated function.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-2484) Dynamic table tests give wrong results when running tests concurrently.
[
https://issues.apache.org/jira/browse/CALCITE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caizhi Weng updated CALCITE-2484:
-
Fix Version/s: (was: 1.18.0)
> Dynamic table tests give wrong results when running tests concurrently.
> ---
>
> Key: CALCITE-2484
> URL: https://issues.apache.org/jira/browse/CALCITE-2484
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Caizhi Weng
>Assignee: Julian Hyde
>Priority: Major
>
> h2. What's happening
> When two dynamic table tests referencing to the same table name run
> concurrently, the results of the tests will be incorrect, causing the tests
> to fail.
> h2. How to reproduce this bug
> As the condition to trigger this bug is strict (two dynamic table tests must
> reference the same table name, and they must run concurrently), it's hard to
> reproduce this bug in the current test set.
> I construct two mock test classes to reproduce this bug stably. The two test
> classes are the same except for their names. One of the test class is listed
> as follows:
> {code:java}
> public class MockSqlValidatorTest1 extends SqlValidatorTestCase {
> // Member definition omitted.
> @Test
> public void testDynamicStar1() {
> final String sql = "select newid from (\n"
> + " select *, NATION.N_NATION + 100 as newid\n"
> + " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
> sql(sql).type("RecordType(ANY NEWID) NOT NULL");
> }
> @Test
> public void testDynamicStar2() {
> final String sql = "select newid from (\n"
> + " select *, NATION.N_NATION + 100 as newid\n"
> + " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
> sql(sql).type("RecordType(ANY NEWID) NOT NULL");
> }
> // 296 more test cases
> @Test
> public void testDynamicStar299() {
> final String sql = "select newid from (\n"
> + " select *, NATION.N_NATION + 100 as newid\n"
> + " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
> sql(sql).type("RecordType(ANY NEWID) NOT NULL");
> }
> @Test
> public void testDynamicStar300() {
> final String sql = "select newid from (\n"
> + " select *, NATION.N_NATION + 100 as newid\n"
> + " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
> sql(sql).type("RecordType(ANY NEWID) NOT NULL");
> }
> {code}
> You can check these two test classes
> [here|https://paste.ubuntu.com/p/rcWYjMzMjf/] and
> [here|https://paste.ubuntu.com/p/Tb2VTz74Xv/] so you can try them out.
> To reproduce this bug, run
> {code}
> mvn -T 4 -Dtest=MockSqlValidatorTest* test -pl core
> {code}
> to run these two test classes concurrently, the bug will occur.
> h2. Why is this happening
> # In the current implementation, when a test class wants to use a
> {{SqlTestFactory}}, it will use {{SqlTestFactory.INSTANCE}}, so every class
> using this factory actually shares the same factory instance.
> # {{catalogReader}} is a member of {{SqlTestFactory}}, so every class
> actually shares the same {{catalogReader}}.
> # As root schema is stored in catalog reader, table is stored in root schema,
> and row type is stored in table, every class actually has access to the same
> row type instance.
> # As dynamic table will modify row type if a column name it wants to use
> doesn't exist, two test cases running concurrently and using the same table
> name may read and modify the same row type instance, causing the result of
> the test to be incorrect, thus causing the failure of the test.
> h2. How to fix this bug
> What I've done in this commit is to remove {{SqlTestFactory.INSTANCE}}, and
> let every test class use a new instance of the factory, so that we can solve
> the concurrent modification problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2484) Dynamic table tests give wrong results when running tests concurrently.
[
https://issues.apache.org/jira/browse/CALCITE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caizhi Weng updated CALCITE-2484:
-
Description:
h2. What's happening
When two dynamic table tests referencing to the same table name run
concurrently, the results of the tests will be incorrect, causing the tests to
fail.
h2. How to reproduce this bug
As the condition to trigger this bug is strict (two dynamic table tests must
reference the same table name, and they must run concurrently), it's hard to
reproduce this bug in the current test set.
I construct two mock test classes to reproduce this bug stably. The two test
classes are the same except for their names. One of the test class is listed as
follows:
{code:java}
public class MockSqlValidatorTest1 extends SqlValidatorTestCase {
// Member definition omitted.
@Test
public void testDynamicStar1() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
@Test
public void testDynamicStar2() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
// 296 more test cases
@Test
public void testDynamicStar299() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
@Test
public void testDynamicStar300() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
{code}
You can check these two test classes
[here|https://paste.ubuntu.com/p/rcWYjMzMjf/] and
[here|https://paste.ubuntu.com/p/Tb2VTz74Xv/] so you can try them out.
To reproduce this bug, run
{code}
mvn -T 4 -Dtest=MockSqlValidatorTest* test -pl core
{code}
to run these two test classes concurrently, the bug will occur.
h2. Why is this happening
# In the current implementation, when a test class wants to use a
{{SqlTestFactory}}, it will use {{SqlTestFactory.INSTANCE}}, so every class
using this factory actually shares the same factory instance.
# {{catalogReader}} is a member of {{SqlTestFactory}}, so every class actually
shares the same {{catalogReader}}.
# As root schema is stored in catalog reader, table is stored in root schema,
and row type is stored in table, every class actually has access to the same
row type instance.
# As dynamic table will modify row type if a column name it wants to use
doesn't exist, two test cases running concurrently and using the same table
name may read and modify the same row type instance, causing the result of the
test to be incorrect, thus causing the failure of the test.
h2. How to fix this bug
What I've done in this commit is to remove {{SqlTestFactory.INSTANCE}}, and let
every test class use a new instance of the factory, so that we can solve the
concurrent modification problem.
was:
h2. What's happening
When two dynamic table tests referencing to the same table name run
concurrently, the results of the tests will be incorrect, causing the tests to
fail.
h2. How to reproduce this bug
As the condition to trigger this bug is strict (two dynamic table tests must
reference the same table name, and they must run concurrently), it's hard to
reproduce this bug in the current test set.
I construct two mock test classes to reproduce this bug stably. The two test
classes are the same except for their names. One of the test class is listed as
follows:
{code:java}
public class MockSqlValidatorTest1 extends SqlValidatorTestCase {
// Member definition omitted.
@Test
public void testDynamicStar1() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
@Test
public void testDynamicStar2() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
// 296 more test cases
@Test
public void testDynamicStar299() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
@Test
public void testDynamicStar300() {
final String sql = "select newid from (\n"
+ "
[jira] [Updated] (CALCITE-2484) Dynamic table tests give wrong results when running tests concurrently.
[
https://issues.apache.org/jira/browse/CALCITE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caizhi Weng updated CALCITE-2484:
-
Description:
h2. What's happening
When two dynamic table tests referencing to the same table name run
concurrently, the results of the tests will be incorrect, causing the tests to
fail.
h2. How to reproduce this bug
As the condition to trigger this bug is strict (two dynamic table tests must
reference the same table name, and they must run concurrently), it's hard to
reproduce this bug in the current test set.
I construct two mock test classes to reproduce this bug stably. The two test
classes are the same except for their names. One of the test class is listed as
follows:
{code:java}
public class MockSqlValidatorTest1 extends SqlValidatorTestCase {
// Member definition omitted.
@Test
public void testDynamicStar1() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
@Test
public void testDynamicStar2() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
// 296 more test cases
@Test
public void testDynamicStar299() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
@Test
public void testDynamicStar300() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
{code}
was:
When running tests on the cluster of my company, I always experience the
failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
investigation, I discover that it is triggered by the cache in
{{DefaultSqlTestFactory}} introduced in [this
commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
The failure of the test case is because:
# In the current implementation, when a test class wants to use a
{{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
every class using this factory actually shares the same factory instance.
# {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
actually shares the same {{cache}}.
# The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares the
same factory instance, every class actually shares the same cache key.
# As catalog reader is stored in cache, root schema is stored in catalog
reader, table is stored in root schema, and row type is stored in table, every
class actually has access to the same row type instance.
# As dynamic table will modify row type if a column name it wants to use
doesn't exist, two test cases running concurrently and using the same table
name may read and modify the same row type instance, causing the result of the
test to be incorrect, thus the failure of the test.
What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let
every test class use a new instance of the factory, so that we can solve the
concurrent modification problem.
> Dynamic table tests give wrong results when running tests concurrently.
> ---
>
> Key: CALCITE-2484
> URL: https://issues.apache.org/jira/browse/CALCITE-2484
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Caizhi Weng
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.18.0
>
>
> h2. What's happening
> When two dynamic table tests referencing to the same table name run
> concurrently, the results of the tests will be incorrect, causing the tests
> to fail.
> h2. How to reproduce this bug
> As the condition to trigger this bug is strict (two dynamic table tests must
> reference the same table name, and they must run concurrently), it's hard to
> reproduce this bug in the current test set.
> I construct two mock test classes to reproduce this bug stably. The two test
> classes are the same except for their names. One of the test class is listed
> as follows:
> {code:java}
> public class MockSqlValidatorTest1 extends SqlValidatorTestCase {
> // Member definition omitted.
> @Test
> public void testDynamicStar1() {
> final String sql = "select newid from (\n"
> + " select *, NATION.N_NATION + 100 as newid\n"
> + " from \"DYNAMIC\".NATION,
[jira] [Reopened] (CALCITE-2484) Dynamic table tests give wrong results when running tests concurrently.
[
https://issues.apache.org/jira/browse/CALCITE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caizhi Weng reopened CALCITE-2484:
--
Sorry for reopening the issue.
After cherry-picking the commit to my own repository, I didn't experience the
test failure on the cluster of my company yesterday.
But this morning I discover that it's just because the "timing" of the tests
are changed. To trigger this bug, two test methods using the same table name
must run concurrently, so the "timing" condition is quite strict to trigger
this bug in the current test set.
I carefully read the changes in CALCITE 2435 and I discover that, although
{{cache}} no longer exists in {{SqlTestFactory}}, {{catalogReader}} is now a
method in {{SqlTestFactory}}. As the test cases still use the same instance of
the factory, they still have access to the same catalog reader. So the problem
still exists.
I construct two mock test classes to trigger this bug stably. The two test
classes are the same except for their names. One of the test class is listed as
follows:
{code:java}
public class MockSqlValidatorTest1 extends SqlValidatorTestCase {
// Member definition omitted.
@Test
public void testDynamicStar1() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
@Test
public void testDynamicStar2() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
// 296 more test cases
@Test
public void testDynamicStar299() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
@Test
public void testDynamicStar300() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
{code}
You can check these two test classes
[here|https://paste.ubuntu.com/p/rcWYjMzMjf/] and
[here|https://paste.ubuntu.com/p/Tb2VTz74Xv/] so you can try them out.
If we use
{code}
mvn -T 4 -Dtest=MockSqlValidatorTest* test -pl core
{code}
to run these two test classes concurrently, the bug will occur.
But if we use
{code}
mvn -Dsurefire.parallel= -Dtest=MockSqlValidatorTest* test -pl core
{code}
to let them run one by one, the bug will not occur.
So we still need to remove the single {{INSTANCE}} of {{SqlTestFactory}}. Each
test class should create and use their own instance of {{SqlTestFactory}} when
they want to use it.
> Dynamic table tests give wrong results when running tests concurrently.
> ---
>
> Key: CALCITE-2484
> URL: https://issues.apache.org/jira/browse/CALCITE-2484
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Caizhi Weng
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.18.0
>
>
> When running tests on the cluster of my company, I always experience the
> failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
> investigation, I discover that it is triggered by the cache in
> {{DefaultSqlTestFactory}} introduced in [this
> commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
> The failure of the test case is because:
> # In the current implementation, when a test class wants to use a
> {{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
> every class using this factory actually shares the same factory instance.
> # {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
> actually shares the same {{cache}}.
> # The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares
> the same factory instance, every class actually shares the same cache key.
> # As catalog reader is stored in cache, root schema is stored in catalog
> reader, table is stored in root schema, and row type is stored in table,
> every class actually has access to the same row type instance.
> # As dynamic table will modify row type if a column name it wants to use
> doesn't exist, two test cases running concurrently and using the same table
> name may read and modify the same row type instance, causing the result of
> the test to be incorrect, thus the failure of the test.
> What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let
> every test class use a
[jira] [Commented] (CALCITE-2484) Dynamic table tests give wrong results when running tests concurrently.
[
https://issues.apache.org/jira/browse/CALCITE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589978#comment-16589978
]
Caizhi Weng commented on CALCITE-2484:
--
[~vladimirsitnikov] This issue will only present when the cache still exists.
As cache is removed in CALCITE 2435, this problem doesn't exist any more. Sorry
I didn't notice that commit.
> Dynamic table tests give wrong results when running tests concurrently.
> ---
>
> Key: CALCITE-2484
> URL: https://issues.apache.org/jira/browse/CALCITE-2484
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Caizhi Weng
>Assignee: Julian Hyde
>Priority: Major
>
> When running tests on the cluster of my company, I always experience the
> failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
> investigation, I discover that it is triggered by the cache in
> {{DefaultSqlTestFactory}} introduced in [this
> commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
> The failure of the test case is because:
> # In the current implementation, when a test class wants to use a
> {{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
> every class using this factory actually shares the same factory instance.
> # {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
> actually shares the same {{cache}}.
> # The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares
> the same factory instance, every class actually shares the same cache key.
> # As catalog reader is stored in cache, root schema is stored in catalog
> reader, table is stored in root schema, and row type is stored in table,
> every class actually has access to the same row type instance.
> # As dynamic table will modify row type if a column name it wants to use
> doesn't exist, two test cases running concurrently and using the same table
> name may read and modify the same row type instance, causing the result of
> the test to be incorrect, thus the failure of the test.
> What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let
> every test class use a new instance of the factory, so that we can solve the
> concurrent modification problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2484) Dynamic table tests give wrong results when running tests concurrently.
[
https://issues.apache.org/jira/browse/CALCITE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caizhi Weng updated CALCITE-2484:
-
Affects Version/s: 1.17.0
> Dynamic table tests give wrong results when running tests concurrently.
> ---
>
> Key: CALCITE-2484
> URL: https://issues.apache.org/jira/browse/CALCITE-2484
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Caizhi Weng
>Assignee: Julian Hyde
>Priority: Major
>
> When running tests on the cluster of my company, I always experience the
> failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
> investigation, I discover that it is triggered by the cache in
> {{DefaultSqlTestFactory}} introduced in [this
> commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
> The failure of the test case is because:
> # In the current implementation, when a test class wants to use a
> {{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
> every class using this factory actually shares the same factory instance.
> # {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
> actually shares the same {{cache}}.
> # The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares
> the same factory instance, every class actually shares the same cache key.
> # As catalog reader is stored in cache, root schema is stored in catalog
> reader, table is stored in root schema, and row type is stored in table,
> every class actually has access to the same row type instance.
> # As dynamic table will modify row type if a column name it wants to use
> doesn't exist, two test cases running concurrently and using the same table
> name may read and modify the same row type instance, causing the result of
> the test to be incorrect, thus the failure of the test.
> What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let
> every test class use a new instance of the factory, so that we can solve the
> concurrent modification problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2484) Dynamic table tests give wrong results when running tests concurrently.
[
https://issues.apache.org/jira/browse/CALCITE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caizhi Weng updated CALCITE-2484:
-
Description:
When running tests on the cluster of my company, I always experience the
failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
investigation, I discover that it is triggered by the cache in
{{DefaultSqlTestFactory}} introduced in [this
commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
The failure of the test case is because:
# In the current implementation, when a test class wants to use a
{{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
every class using this factory actually shares the same factory instance.
# {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
actually shares the same {{cache}}.
# The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares the
same factory instance, every class actually shares the same cache key.
# As catalog reader is stored in cache, root schema is stored in catalog
reader, table is stored in root schema, and row type is stored in table, every
class actually has access to the same row type instance.
# As dynamic table will modify row type if a column name it wants to use
doesn't exist, two test cases running concurrently and using the same table
name may read and modify the same row type instance, causing the result of the
test to be incorrect, thus the failure of the test.
What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let
every test class use a new instance of the factory, so that we can solve the
concurrent modification problem.
was:
When running tests on the cluster of my company, I always experience the
failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
investigation, I discover that it is triggered by the cache in
{{DefaultSqlTestFactory}} introduced in [this
commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
The failure of the test case is because:
# In the current implementation, when a test class wants to use a
{{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
every class using this factory actually shares the same factory instance.
# {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
actually shares the same {{cache}}.
# The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares the
same factory instance, every class actually shares the same cache key.
# As catalog reader is stored in cache, root schema is stored in catalog
reader, table is stored in root schema, and row type is stored in table, every
class actually has access to the same row type instance.
# As dynamic table will modify row type if a column name it wants to use
doesn't exist, two test cases using the same table name may read and modify the
same row type instance, causing the result of the test to be incorrect, thus
the failure of the test.
What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let
every test class use a new instance of the factory, so that we can solve the
concurrent modification problem.
> Dynamic table tests give wrong results when running tests concurrently.
> ---
>
> Key: CALCITE-2484
> URL: https://issues.apache.org/jira/browse/CALCITE-2484
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Caizhi Weng
>Assignee: Julian Hyde
>Priority: Major
>
> When running tests on the cluster of my company, I always experience the
> failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
> investigation, I discover that it is triggered by the cache in
> {{DefaultSqlTestFactory}} introduced in [this
> commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
> The failure of the test case is because:
> # In the current implementation, when a test class wants to use a
> {{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
> every class using this factory actually shares the same factory instance.
> # {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
> actually shares the same {{cache}}.
> # The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares
> the same factory instance, every class actually shares the same cache key.
> # As catalog reader is stored in cache, root schema is stored in catalog
> reader, table is stored in root schema, and row type is stored in table,
> every class actually has access to the same row type instance.
> # As dynamic table will modify row type if a column name it wants to use
> doesn't exist, two test cases running
[jira] [Updated] (CALCITE-2484) Dynamic table tests give wrong results when running tests concurrently.
[
https://issues.apache.org/jira/browse/CALCITE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caizhi Weng updated CALCITE-2484:
-
Description:
When running tests on the cluster of my company, I always experience the
failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
investigation, I discover that it is triggered by the cache in
{{DefaultSqlTestFactory}} introduced in [this
commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
The failure of the test case is because:
# In the current implementation, when a test class wants to use a
{{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
every class using this factory actually shares the same factory instance.
# {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
actually shares the same {{cache}}.
# The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares the
same factory instance, every class actually shares the same cache key.
# As catalog reader is stored in cache, root schema is stored in catalog
reader, table is stored in root schema, and row type is stored in table, every
class actually has access to the same row type instance.
# As dynamic table will modify row type if a column name it wants to use
doesn't exist, two test cases using the same table name may read and modify the
same row type instance, causing the result of the test to be incorrect, thus
the failure of the test.
What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let
every test class use a new instance of the factory, so that we can solve the
concurrent modification problem.
was:
When running tests on the cluster of my company, I always experience the
failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
investigation, I discover that it is triggered by the cache in
{{DefaultSqlTestFactory}} introduced in [this
commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
The failure of the test case is because:
# In the current implementation, when a test class wants to use a
{{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
every class using this factory actually shares the same instance.
# {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
actually shares the same {{cache}}.
# The key of {{cache}} is of {{SqlTestFactory}} type, as every class shares the
same factory instance, every class actually shares the same cache key.
# As catalog reader is stored in cache, root schema is stored in catalog
reader, table is stored in root schema, and row type is stored in table, every
class actually has access to the same row type instance.
# As dynamic table will modify row type if a column name it wants to use
doesn't exist, two test cases using the same table name may read and modify the
same row type instance, causing the result of the test to be incorrect, thus
the failure of the test.
What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let
every test class use a new instance of the factory, so that we can solve the
concurrent modification problem.
> Dynamic table tests give wrong results when running tests concurrently.
> ---
>
> Key: CALCITE-2484
> URL: https://issues.apache.org/jira/browse/CALCITE-2484
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Caizhi Weng
>Assignee: Julian Hyde
>Priority: Major
>
> When running tests on the cluster of my company, I always experience the
> failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
> investigation, I discover that it is triggered by the cache in
> {{DefaultSqlTestFactory}} introduced in [this
> commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
> The failure of the test case is because:
> # In the current implementation, when a test class wants to use a
> {{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
> every class using this factory actually shares the same factory instance.
> # {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
> actually shares the same {{cache}}.
> # The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares
> the same factory instance, every class actually shares the same cache key.
> # As catalog reader is stored in cache, root schema is stored in catalog
> reader, table is stored in root schema, and row type is stored in table,
> every class actually has access to the same row type instance.
> # As dynamic table will modify row type if a column name it wants to use
> doesn't exist, two test cases using the same table name may read and modify
[jira] [Created] (CALCITE-2484) Dynamic table tests give wrong results when running tests concurrently.
Caizhi Weng created CALCITE-2484:
Summary: Dynamic table tests give wrong results when running tests
concurrently.
Key: CALCITE-2484
URL: https://issues.apache.org/jira/browse/CALCITE-2484
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Caizhi Weng
Assignee: Julian Hyde
When running tests on the cluster of my company, I always experience the
failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
investigation, I discover that it is triggered by the cache in
{{DefaultSqlTestFactory}} introduced in [this
commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
The failure of the test case is because:
# In the current implementation, when a test class wants to use a
{{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
every class using this factory actually shares the same instance.
# {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
actually shares the same {{cache}}.
# The key of {{cache}} is of {{SqlTestFactory}} type, as every class shares the
same factory instance, every class actually shares the same cache key.
# As catalog reader is stored in cache, root schema is stored in catalog
reader, table is stored in root schema, and row type is stored in table, every
class actually has access to the same row type instance.
# As dynamic table will modify row type if a column name it wants to use
doesn't exist, two test cases using the same table name may read and modify the
same row type instance, causing the result of the test to be incorrect, thus
the failure of the test.
What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let
every test class use a new instance of the factory, so that we can solve the
concurrent modification problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2482) Fix result for COVAR_POP, COVAR_SAMP, REGR_SXX, REGR_SYY
Caizhi Weng created CALCITE-2482:
Summary: Fix result for COVAR_POP, COVAR_SAMP, REGR_SXX, REGR_SYY
Key: CALCITE-2482
URL: https://issues.apache.org/jira/browse/CALCITE-2482
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Caizhi Weng
Assignee: Julian Hyde
There are two situations where REGR_SXX, REGR_SYY, COVAR_POP and COVAR_SAMP may
produce undesired results using the current implementation provided from the
pull request of [CALCITE 2402].
*1. When a filter is applied along with REGR_SXX, REGR_SYY, etc., the filter
will be ignored due to the bug when reducing these aggregate functions.*
Consider the following query:
{code:sql}
SELECT
regr_sxx(a, b) filter (where a <= 0) as "REGR_SXX(A, B)"
from (values (1, 1), (2, 2), (3, 3)) as t(a, b);
{code}
It's easy to discover that the answer should be null, as no row matches the
filter condition. But the current implementation gives 2 as the answer.
*2. If the user implements the {{deriveCovarType}} of the
{{RelDataTypeSystem}}, the result of REGR_SXX, REGR_SYY, etc. might not be the
desired result.*
Consider the following query:
{code:sql}
SELECT
regr_sxx(a, b) as "REGR_SXX(A, B)"
from (values (1, 1), (2, 2)) as t(a, b);
{code}
Current implementation in Calcite provides 1 as the answer (precisely speaking,
it's 0.5 rounds up to 1).
This result is OK for the default implementation of {{deriveCovarType}}. But if
the user implements his own {{deriveCovarType}} (for example, he explicitly
sets the result type of the function to {{double}}), 1 is not the desired
result.
What we need to do is to fix the filter problem, and make sure that the
operands of the division operation in REGR_SXX are of the desired type.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
