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

Reply via email to