MetadataFactory's implementation provides a unified, reflective approach to retrieve metadata, no matter the metadata is builtin or extended type. RelMetadataQuery provides convenient methods (in codegen) to get builtin metadata, but not for costomized metadata. Unless we recommend sub-classing RelMetadataQuery as the way to add costomized metadata, deprecating MetadataFactory is not a wise choice.
- Haisheng ------------------------------------------------------------------ 发件人：XING JIN<jinxing.co...@gmail.com> 日 期：2019年10月17日 15:55:31 收件人：<dev@calcite.apache.org> 主 题：Re: [DISCUSSION] Extension of Metadata Query 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 >> >>
