That is the point, we should supply a way to extend the RelMetadataQuery conveniently for Calcite, because in most of the RelOptRules, user would use the code like:
RelOptRuleCall.getMetadataQuery To get a RMQ instead of using AbstractRelNode.metadata() to fetch a MedataFactory. We should at lest unity the metadata query entrance/interfaces, or it would confuse a lot. Best, Danny Chan 在 2019年10月18日 +0800 AM12:23，Seliverstov Igor <gvvinbl...@gmail.com>，写道： > At least in our project (Apache Ignite) we use AbstractRelNode.metadata(). > > But it so because there is no way to put our metadata type into > RelMetadataQuery without changes in Calcite. > > Regards, > Igor > > чт, 17 окт. 2019 г., 19:16 Xiening Dai <xndai....@gmail.com>: > > > MetadataFactory is still useful. It provides a way to access Metadata > > directly. If someone creates a new type of Metadata class, it can be > > accessed through AbstractRelNode.metadata(). This way you don’t need to > > update RelMetadataQuery interface to include the getter for this new meta. > > Although I don’t see this pattern being used often, but I do think it is > > still useful and shouldn’t be removed. > > > > > > For your second point, I think you would still need a way to keep > > RelMetadataQuery object during a rule call. If you choose to create new > > instance, you will have to pass it around while applying the rule. That > > actually complicates things a lot. > > > > > > > On Oct 17, 2019, at 12:49 AM, XING JIN <jinxing.co...@gmail.com> wrote: > > > > > > 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 > > > > > > > > > > > >
