[
https://issues.apache.org/jira/browse/CALCITE-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16336166#comment-16336166
]
Paul Jackson commented on CALCITE-2146:
---------------------------------------
I've spent some time looking at how to copy a generic RelNode into its own
cluster. If I knew at compile time what the RelNode was this would be easy, but
these templates are coming from user-supplied SQL that we run through
{{SqlToRelConverter}}. I don't want to have to rerun that every time I run a
query.
The only way I see to clone a RelNode is through the {{RelNode.copy(RelTraitSet
traitSet, List<RelNode> inputs)}} interface, but the implementations generally
call {{AbstractRelNode.getCluster()}} to obtain the cluster. I'd need an
overload of the copy method that takes a RelOptCluster as an argument for this
approach to work. It looks like a significant change - by my count there are 75
classes with a copy method that calls getCluster() in core, alone.
The only way I see for me to achieve this without changing Calcite is to create
a Factory that takes a RelNode and a Cluster and, through a large if/then/else,
tests the class type and calls a constructor for every possible subclass.
Am I missing something?
> Errant CyclicMetadataException in multithreaded context
> -------------------------------------------------------
>
> Key: CALCITE-2146
> URL: https://issues.apache.org/jira/browse/CALCITE-2146
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.15.0
> Reporter: Paul Jackson
> Assignee: Julian Hyde
> Priority: Major
>
> The code that protects against cyclic metadata is not thread-safe. A typical
> stack trace looks like:
> {{Caused by: org.apache.calcite.rel.metadata.CyclicMetadataException}}
> {{ at
> org.apache.calcite.rel.metadata.CyclicMetadataException.<clinit>(CyclicMetadataException.java:28)}}
> {{ at GeneratedMetadataHandler_Collation.collations(Unknown Source)}}
> {{ at GeneratedMetadataHandler_Collation.collations_$(Unknown Source)}}
> {{ at GeneratedMetadataHandler_Collation.collations(Unknown Source)}}
> {{ at
> org.apache.calcite.rel.metadata.RelMetadataQuery.collations(RelMetadataQuery.java:563)}}
> {{ at
> org.apache.calcite.rel.metadata.RelMdCollation.collations(RelMdCollation.java:117)}}
> {{ at GeneratedMetadataHandler_Collation.collations_$(Unknown Source)}}
> {{ at GeneratedMetadataHandler_Collation.collations(Unknown Source)}}
> {{ at GeneratedMetadataHandler_Collation.collations_$(Unknown Source)}}
> {{ at GeneratedMetadataHandler_Collation.collations(Unknown Source)}}
> {{ at
> org.apache.calcite.rel.metadata.RelMetadataQuery.collations(RelMetadataQuery.java:563)}}
> {{ at
> org.apache.calcite.rel.metadata.RelMdCollation.project(RelMdCollation.java:207)}}
> {{ at
> org.apache.calcite.rel.logical.LogicalProject$1.get(LogicalProject.java:117)}}
> {{ at
> org.apache.calcite.rel.logical.LogicalProject$1.get(LogicalProject.java:115)}}
> {{ at org.apache.calcite.plan.RelTraitSet.replaceIfs(RelTraitSet.java:238)}}
> {{ at
> org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:113)}}
> {{ at
> org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:103)}}
> {{ at
> org.apache.calcite.rel.core.RelFactories$ProjectFactoryImpl.createProject(RelFactories.java:127)}}
> {{ at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1064)}}
> Generally, the use case that causes this is one where we have a set of SQL
> templates represented as RelNodes, which we use as a starting point for
> queries. If different threads operate on the same RelNode, they may work on
> the same cluster, and therefore the same RelMetadataQuery instance, which
> contains a map instance that is used to detect Cyclic Metadata.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
