[
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
> 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)
