+1 on Danny's comment. If we use MedataFactory to customize and use RelMetadataQuery for convenience, that will make user confused.
Danny Chan <yuzhao....@gmail.com> 于2019年10月18日周五 下午12:33写道： > 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 > > > > > > > > > > > > > > > > >
