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