BTW, I think one JIRA number discussed in the thread would be https://issues.apache.org/jira/browse/CALCITE-2855 not CALCITE-2885
Best, Jin XING JIN <jinxing.co...@gmail.com> 于2019年10月17日周四 下午3:49写道： > 1. RelMetadataQuery covers the functionality of MetadataFactory, why > should we keep/maintain both of them ? shall we just > deprecate MetadataFactory. I see MetadataFactory is rarely used in current > code. Also I think MetadataFactory is not good place to offering customized > metadata, which will make user confused for the difference > between RelMetadataQuery and MetadataFactory. > > > Customized RelMetadataQuery with code generated meta handler for > customized metadata, also can provide convenient way to get metadata. > It makes sense for me. > > 2. If the natural lifespan of a RelMetadataQuery is a RelOptCall, shall we > deprecate RelOptCluster#getMetadataQuery ? If a user wants to get the > metadata but without a RelOptCall, he/she will need to create a new > instance of RelMetadataQuery. > > Xiening Dai <xndai....@gmail.com> 于2019年10月17日周四 上午2:27写道： > >> I have seen both patterns in current code base. In most places, for >> example SubQueryRemoveRule, AggregateUnionTrasposeRule >> SortJoinTransposeRule, etc., RelOptCluster.getMetadataQuery() is used. And >> there are a few other places where new RelMetadataQuery instance is >> created, which Haisheng attempts to fix. >> >> Currently RelOptCluster.invalidateMetadataQuery() is called at the end of >> RelOptRuleCall.transformTo(). So the lifespan of RelMetadataQuery is >> guaranteed to be within a RelOptCall. I think Haisheng’s fix is safe. >> >> >> > On Oct 16, 2019, at 1:53 AM, Danny Chan <yuzhao....@gmail.com> wrote: >> > >> > This is the reason I was struggling for the discussion. >> > >> > Best, >> > Danny Chan >> > 在 2019年10月16日 +0800 AM11:23，dev@calcite.apache.org，写道： >> >> >> >> RelMetadataQuery >> >>
