[FLINK-31409][hive] Hive dialect should use public interfaces #22166

luoyuxia · 2023-03-13T05:05:33Z

What is the purpose of the change

This is to make Hive dialect use public interfaces provided by pluggable dialect.
After this, we can then remove provided dependency of flink-table-planner in FLINK-31413

Brief change log

The basic idea comes from FLIP-216.

In first commit, we introduce a slim module named flink-table-calcite-bridge which ships calcite dependency and provide a CalciteContext usded by other plugin module. In the next pr, we can then make hive-connector depend on flink-table-calcite-bridge
In second commit, we introudce or expose some public interfaces like DialectFactory/CatalogRegistry for pulgin dialect .
Something to add, in here we remove ExtendedOperationExecutor, as a result of which we wrap the logic in HiveExtendedOperationExecutor to HiveExecutableOperation. HiveExecutableOperation will delegate the execution logic to HiveExtendedOperationExecutor in method execute. It's some hack logic and will be refactor in other pr.
In thrid commit, we make HiveParser use public interface CatalogRegistry and an internal inteface CalciteContext instead of internal class/interfaces like CatalogManager/FlinkPlannerImpl/PlannerContext, ...

Verifying this change

The change has been verified by existing tests.

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

flinkbot · 2023-03-13T05:09:56Z

CI report:

9a53507 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

@flinkbot run azure re-run the last Azure build

snuyanzin · 2023-03-13T07:36:53Z

flink-table/flink-table-calcite-bridge/pom.xml

+				"mvn dependency:tree" as of Calcite 1.26.0:
+				[INFO] +- org.apache.calcite:calcite-core:jar:1.26.0:compile
+				[INFO] |  +- org.apache.calcite:calcite-linq4j:jar:1.26.0:compile
+				[INFO] |  +- com.fasterxml.jackson.core:jackson-annotations:jar:2.12.1:compile
+				[INFO] |  +- org.apiguardian:apiguardian-api:jar:1.1.0:compile
+				[INFO] |  +- com.esri.geometry:esri-geometry-api:jar:2.2.0:runtime
+				[INFO] |  +- com.fasterxml.jackson.core:jackson-core:jar:2.12.1:runtime
+				[INFO] |  +- com.fasterxml.jackson.core:jackson-databind:jar:2.12.1:runtime
+				[INFO] |  +- com.jayway.jsonpath:json-path:jar:2.4.0:runtime
+				[INFO] |  |  \- net.minidev:json-smart:jar:2.3:runtime
+				[INFO] |  |     \- net.minidev:accessors-smart:jar:1.2:runtime
+				[INFO] |  |        \- org.ow2.asm:asm:jar:5.0.4:runtime
+				[INFO] |  +- commons-codec:commons-codec:jar:1.10:runtime
+				[INFO] |  +- org.apache.commons:commons-lang3:jar:3.3.2:compile
+				[INFO] |  \- commons-io:commons-io:jar:2.4:compile


it should be 1.29.0 dependencies like at https://github.com/apache/flink/pull/22166/files#diff-6d81d722fce4e303d49b2136ae8e137f74ed3f4ece4d2a990445bcf6a2388392L132-L147

Suggested change

"mvn dependency:tree" as of Calcite 1.26.0:

[INFO] +- org.apache.calcite:calcite-core:jar:1.26.0:compile

[INFO] | +- org.apache.calcite:calcite-linq4j:jar:1.26.0:compile

[INFO] | +- com.fasterxml.jackson.core:jackson-annotations:jar:2.12.1:compile

[INFO] | +- org.apiguardian:apiguardian-api:jar:1.1.0:compile

[INFO] | +- com.esri.geometry:esri-geometry-api:jar:2.2.0:runtime

[INFO] | +- com.fasterxml.jackson.core:jackson-core:jar:2.12.1:runtime

[INFO] | +- com.fasterxml.jackson.core:jackson-databind:jar:2.12.1:runtime

[INFO] | +- com.jayway.jsonpath:json-path:jar:2.4.0:runtime

[INFO] | | \- net.minidev:json-smart:jar:2.3:runtime

[INFO] | | \- net.minidev:accessors-smart:jar:1.2:runtime

[INFO] | | \- org.ow2.asm:asm:jar:5.0.4:runtime

[INFO] | +- commons-codec:commons-codec:jar:1.10:runtime

[INFO] | +- org.apache.commons:commons-lang3:jar:3.3.2:compile

[INFO] | \- commons-io:commons-io:jar:2.4:compile

"mvn dependency:tree" as of Calcite 1.29.0:

[INFO] +- org.apache.calcite:calcite-core:jar:1.29.0:compile

[INFO] | +- org.apache.calcite:calcite-linq4j:jar:1.29.0:compile

[INFO] | +- com.esri.geometry:esri-geometry-api:jar:2.2.0:compile

[INFO] | +- com.fasterxml.jackson.core:jackson-annotations:jar:2.13.4:compile

[INFO] | +- org.apache.calcite.avatica:avatica-core:jar:1.20.0:compile

[INFO] | +- com.fasterxml.jackson.core:jackson-core:jar:2.13.4:compile

[INFO] | +- com.fasterxml.jackson.core:jackson-databind:jar:2.13.4.2:compile

[INFO] | +- com.jayway.jsonpath:json-path:jar:2.4.0:runtime

[INFO] | | \- net.minidev:json-smart:jar:2.3:runtime

[INFO] | | \- net.minidev:accessors-smart:jar:1.2:runtime

[INFO] | | \- org.ow2.asm:asm:jar:5.0.4:runtime

[INFO] | +- commons-codec:commons-codec:jar:1.15:runtime

[INFO] | \- commons-io:commons-io:jar:2.11.0:compile

luoyuxia · 2023-03-17T10:01:38Z

@wuchong @lincoln-lil Could you please help review when you are free.

lincoln-lil

@luoyuxia thanks for driving the hive decoupling! Overall looks good to me, and I've left some minor comments.

lincoln-lil · 2023-03-20T06:06:52Z

...ink-table-planner/src/main/scala/org/apache/flink/table/planner/delegation/PlannerBase.scala

    parser
  }

+  def getOperationTreeBuilder: OperationTreeBuilder = {


this can be 'private'

lincoln-lil · 2023-03-20T06:07:17Z

...ink-table-planner/src/main/scala/org/apache/flink/table/planner/delegation/PlannerBase.scala

+    )
+  }
+
+  def getTableReferenceExpression(path: String): Optional[TableReferenceExpression] = {


lincoln-lil · 2023-03-20T07:11:25Z

...ink-table-planner/src/main/scala/org/apache/flink/table/planner/delegation/PlannerBase.scala

+        Optional.of(ApiExpressionUtils.tableRef(path, queryOperation))
+      }
+    } catch {
+      case _: SqlParserException => Optional.empty()


Why is the exception here not thrown directly? Are there any test cases related to this exception path?

It's copied from TableEnvironmentImpl, I think we can also copy comment to here.
Haven't find any test cases related to this exception path. Considering it's copied from existing codebase , may be we can add test in a dedicated pr if need.

sounds good to create another followup issue to add a related test

lincoln-lil · 2023-03-20T08:12:58Z

...k-sql-gateway/src/main/java/org/apache/flink/table/gateway/service/result/ResultFetcher.java

+            resultRows = tableResultInternal.collectInternal();
+            rowDataToStringConverter = tableResultInternal.getRowDataToStringConverter();
+        } else {
+            // sometime, the tableResult maybe not an instance of TableResultInternal


nit: 'sometimes'

lincoln-lil

LGTM +1

lincoln-lil · 2023-03-21T03:59:44Z

...ink-table-planner/src/main/scala/org/apache/flink/table/planner/delegation/PlannerBase.scala

+        Optional.of(ApiExpressionUtils.tableRef(path, queryOperation))
+      }
+    } catch {
+      case _: SqlParserException => Optional.empty()


sounds good to create another followup issue to add a related test

lincoln-lil · 2023-03-21T04:03:35Z

@luoyuxia seems the latest change failed to pass the style check, PTAL
otherwise +1

luoyuxia · 2023-03-21T06:39:27Z

@flinkbot run azure

wuchong · 2023-03-22T02:07:38Z

...table-calcite-bridge/src/main/java/org/apache/flink/table/calcite/bridge/CalciteContext.java

+    FunctionCatalog getFunctionCatalog();
+
+    /**
+     * Create the {@link RelOptTable.ToRelContext} used t0 convert a table into a relational


Suggested change

* Create the {@link RelOptTable.ToRelContext} used t0 convert a table into a relational

* Create a new instance of {@link RelOptTable.ToRelContext} used to convert a table into a relational

wuchong · 2023-03-23T16:17:59Z

...ble/flink-table-api-java/src/main/java/org/apache/flink/table/delegation/DialectFactory.java

    Parser create(Context context);

+    /** Create an extended operation executor. */
    default ExtendedOperationExecutor createExtendedOperationExecutor(Context context) {


I'm thinking of removing the ExtendedOperationExecutor because we have introduced ExecutableOperation which is a self-contained way to support the operation execution. In this way, we can rename DialectFactory back to ParserFactory to align with the original FLIP proposal.

Removing ExtendedOperationExecutor is good idea. It makes everything simple. I have updated it for removing and renming.
Hope the internal ExecutableOperation interface won't change frequently

wuchong · 2023-03-23T16:45:26Z

...k-sql-gateway/src/main/java/org/apache/flink/table/gateway/service/result/ResultFetcher.java

+        } else {
+            // sometimes, the tableResult maybe not an instance of TableResultInternal
+            // in the case of pluggable dialect implements method
+            // ExtendedOperationExecutor#executeOperation, and it doesn't return TableResultInternal


Which case doesn't return TableResultInternal?

Previous, we have ExtendedOperationExecutor#executeOperation marked as PublicEvolving, so the result of this method should be TableResult which is also marked as PublicEvolving. Since this interface don't require implementer to return TableResultInternal, the implementer can return anything that implements TableResult.

But now, I have removed ExtendedOperationExecutor and reverted this change.

wuchong · 2023-03-23T16:47:13Z

...ble-api-java/src/main/java/org/apache/flink/table/api/internal/TableEnvironmentInternal.java

     * @return the content of the execution result.
     */
-    TableResultInternal executeInternal(Operation operation);
+    TableResult executeInternal(Operation operation);


Why do we need to change this?

Previous, we have ExtendedOperationExecutor#executeOperation marked as PublicEvolving, so the result of this method should be TableResult which is also marked as PublicEvolving. So we should also change it to TableResult in here.

Now, I revert this changes since we remove ExtendedOperationExecutor.

wuchong · 2023-03-23T16:57:05Z

...ink-table-planner/src/main/scala/org/apache/flink/table/planner/delegation/PlannerBase.scala

+  private def getOperationTreeBuilder: OperationTreeBuilder = {
+    OperationTreeBuilderImpl.create(
+      tableConfig,
+      classLoader,
+      functionCatalog.asLookup(f => getParser.parseIdentifier(f)),
+      catalogManager.getDataTypeFactory,
+      (path: String) => getTableReferenceExpression(path),
+      (s: String, inputRowType: RowType, outputType) =>
+        getParser.parseSqlExpression(s, inputRowType, outputType),
+      isStreamingMode
+    )
+  }


The creation of OperationTreeBuilderImpl is super complex, and the logic is duplicated. This is difficult to maintain logic consistency in the future.

Besides, the extracted OperationTreeBuilder seems incomplete (e.g, join) and is never used. I would prefer to introduce the OperationTreeBuilder when we indeed need this, otherwise, it only increases the overhead of maintenance. What do you think?

I do agree. We can add it in the future when we do need it. That does make everything simple.

Btw, the reason that OperationTreeBuilder miss join is the JoinType is not marked as PublicEvolving , so we can't expose it in OperationTreeBuilder.

luoyuxia · 2023-03-24T09:52:50Z

I reoriginize the commits intead of appending for this change make append commit hard to track. I also update the brief change log in the description for this pr.

wuchong

Thank you for the update. I think this is in good shape. During reviewing the code, I find the methods of CatalogRegistry are not smooth to use. For example,

the ResolvedCatalogBaseTable vs ContextResolvedTable mentioned above,
the Optional return type is trivial, we always throw exceptions when working with an empty Optional result.
it's a long method chain to get the current catalog, but this is a frequent call.

I'm thinking about revisiting the design of CatalogRegistry into this:

/** A catalog registry for dealing with catalogs. */
@PublicEvolving
public interface CatalogRegistry {
    /** Get the current database. */
    String getCurrentDatabase();

    /** Gets the current catalog. */
    String getCurrentCatalog();

    /**
     * Returns the full name of the given table path, this name may be padded with current
     * catalog/database name based on the {@code identifier's} length.
     *
     * @param identifier an unresolved identifier
     * @return a fully qualified object identifier
     */
    ObjectIdentifier qualifyIdentifier(UnresolvedIdentifier identifier);

    /** Gets the current catalog. */
    Catalog getCurrentCatalog();

    /**
     * Gets a catalog by name.
     *
     * @param catalogName name of the catalog to retrieve
     * @return the requested catalog
     * @throws CatalogNotExistException if the catalog does not exist
     */
    Catalog getCatalogOrError(String catalogName);

    /**
     * Gets a fully qualified and resolved table with context by name. If the path is not yet fully
     * qualified use {@link #qualifyIdentifier(UnresolvedIdentifier)} first.
     *
     * @param objectIdentifier full path of the table to retrieve
     * @return resolved table with context that the path points to
     * @throws TableNotExistException if the table does not exist
     */
    ContextResolvedTable getTableOrError(ObjectIdentifier objectIdentifier);

    /**
     * Return whether the table with a fully qualified table path is temporary or not.
     *
     * @param objectIdentifier full path of the table
     * @return the table is temporary or not.
     */
    boolean isTemporaryTable(ObjectIdentifier objectIdentifier);

    /**
     * Retrieves a partition with a fully qualified table path and partition spec.
     *
     * @param tableIdentifier full path of the table to retrieve
     * @param partitionSpec full partition spec
     * @return partition in the table.
     */
    Optional<CatalogPartition> getPartition(
            ObjectIdentifier tableIdentifier, CatalogPartitionSpec partitionSpec);
    
    /**
     * Retrieves a partition with a fully qualified table path and partition spec.
     *
     * @param tableIdentifier full path of the table to retrieve
     * @param partitionSpec full partition spec
     * @return partition in the table.
     * @throws PartitionNotExistException if the partition does not exist
     */
    CatalogPartition getPartitionOrError(
            ObjectIdentifier tableIdentifier, CatalogPartitionSpec partitionSpec);
}

What do you think?

wuchong · 2023-04-23T07:43:28Z

...r-hive/src/main/java/org/apache/flink/table/planner/delegation/hive/HiveParserDMLHelper.java

                Collections.emptyMap());
    }

+    private ContextResolvedTable getContextResolvedTable(ObjectIdentifier tableIdentifier) {


It seems we still need to depend on ContextResolvedTable, which is an @Internal class. The getContextResolvedTable method is somehow duplicated with CatalogManager#getTable. Besides, I don't favor the verbose method signature of CatalogRegistry#getResolvedCatalogBaseTable. What do you think about replacing the CatalogRegistry#getResolvedCatalogBaseTable with CatalogRegistry#getTableOrError? This can also make the callers easier without dealing with the empty result.

Yes, we still needs to depend on ContextResolvedTable for it's need to construct SinkModifyOperation which is also @Internal. In fact, Hive dialect still use many internal operations. Maybe we need to expose them to public then, but it may be another topic.
Considering our plan is decoupling Hive with flink-table-planner in the first, I think we can keep them to see how much these internal interfaces/classes will affect the maintainance/development of Hive dialect to take further steps.
Btw, it make me be aware of the title of the pr/jira is not correct, it should be Hive dialect shouldn't use interfaces in table-planner to build LogicPlan.

wuchong · 2023-04-23T07:44:33Z

...tor-hive/src/main/java/org/apache/flink/table/planner/delegation/hive/HiveParserFactory.java

-    @Override
-    public ExtendedOperationExecutor createExtendedOperationExecutor(Context context) {
-        return new HiveOperationExecutor(context.getCatalogManager(), context.getPlannerContext());
+        return new HiveParser((CalciteContext) context);


Please add a comment about the hard cast.

…anner to build LogicPlan

…t: refine interface to address comments

luoyuxia · 2023-04-26T11:36:44Z

Thank you for the update. I think this is in good shape. During reviewing the code, I find the methods of CatalogRegistry are not smooth to use. For example,

the ResolvedCatalogBaseTable vs ContextResolvedTable mentioned above,
the Optional return type is trivial, we always throw exceptions when working with an empty Optional result.
it's a long method chain to get the current catalog, but this is a frequent call.

I'm thinking about revisiting the design of CatalogRegistry into this:

/** A catalog registry for dealing with catalogs. */
@PublicEvolving
public interface CatalogRegistry {
    /** Get the current database. */
    String getCurrentDatabase();

    /** Gets the current catalog. */
    String getCurrentCatalog();

    /**
     * Returns the full name of the given table path, this name may be padded with current
     * catalog/database name based on the {@code identifier's} length.
     *
     * @param identifier an unresolved identifier
     * @return a fully qualified object identifier
     */
    ObjectIdentifier qualifyIdentifier(UnresolvedIdentifier identifier);

    /** Gets the current catalog. */
    Catalog getCurrentCatalog();

    /**
     * Gets a catalog by name.
     *
     * @param catalogName name of the catalog to retrieve
     * @return the requested catalog
     * @throws CatalogNotExistException if the catalog does not exist
     */
    Catalog getCatalogOrError(String catalogName);

    /**
     * Gets a fully qualified and resolved table with context by name. If the path is not yet fully
     * qualified use {@link #qualifyIdentifier(UnresolvedIdentifier)} first.
     *
     * @param objectIdentifier full path of the table to retrieve
     * @return resolved table with context that the path points to
     * @throws TableNotExistException if the table does not exist
     */
    ContextResolvedTable getTableOrError(ObjectIdentifier objectIdentifier);

    /**
     * Return whether the table with a fully qualified table path is temporary or not.
     *
     * @param objectIdentifier full path of the table
     * @return the table is temporary or not.
     */
    boolean isTemporaryTable(ObjectIdentifier objectIdentifier);

    /**
     * Retrieves a partition with a fully qualified table path and partition spec.
     *
     * @param tableIdentifier full path of the table to retrieve
     * @param partitionSpec full partition spec
     * @return partition in the table.
     */
    Optional<CatalogPartition> getPartition(
            ObjectIdentifier tableIdentifier, CatalogPartitionSpec partitionSpec);
    
    /**
     * Retrieves a partition with a fully qualified table path and partition spec.
     *
     * @param tableIdentifier full path of the table to retrieve
     * @param partitionSpec full partition spec
     * @return partition in the table.
     * @throws PartitionNotExistException if the partition does not exist
     */
    CatalogPartition getPartitionOrError(
            ObjectIdentifier tableIdentifier, CatalogPartitionSpec partitionSpec);
}

What do you think?

Thanks for the advice, I like the idea that getOrError to make caller easy to use.
So, I add getCatalogOrError to this method since it'll always throw error in Hive dialect if the catalog doesn't exist.

But for some other methods getTableOrError, the HiveParser actually won't always throw exception in this method .
So, we'll still need another method getTable which returns an option.

And for the method getPartitionOrError, it will throw PartitionNotExistException which is not a runtime exception.
The caller like HiveParser will still need to catch the exception and then wrap it to a RunTimeException. For me, it seems not to be much easy to call this method, at lest in HiveParser with existing codebase.

Beside, I'm trying to expose less interfaces in this case that it seems not as so inconvenient to use to me and some extra interfaces seem to be verbose/duplicated to me.

Btw, ContextResolvedTable is an Internal class, so we still can't return ContextResolvedTable in method CatalogRegistry#getResolvedCatalogBaseTable. To simply the name, I rename it to CatalogRegistry#getCatalogBaseTable.

…anner to build LogicPlan: address comments

luoyuxia · 2023-04-26T11:41:09Z

@wuchong Thanks for your review. I have addressed your comments in 9e508a,
9a5350.

wuchong

@luoyuxia thank you for the update. LGTM.

luoyuxia · 2023-04-27T02:03:39Z

Thanks all for the review. :-)

…anner to build LogicPlan This closes apache#22166

luoyuxia force-pushed the FLINK-31409 branch from 4a155ed to d87e66e Compare March 13, 2023 06:04

luoyuxia marked this pull request as draft March 13, 2023 06:08

luoyuxia marked this pull request as ready for review March 13, 2023 06:21

luoyuxia changed the title ~~Flink 31409~~ [FLINK-31409][hive] Hive connector should use public interfaces for Hive dialct Mar 13, 2023

luoyuxia force-pushed the FLINK-31409 branch from d87e66e to 8af34f6 Compare March 13, 2023 07:19

luoyuxia changed the title ~~[FLINK-31409][hive] Hive connector should use public interfaces for Hive dialct~~ [FLINK-31409][hive] Hive dialect should use public interfaces Mar 13, 2023

luoyuxia force-pushed the FLINK-31409 branch from 8af34f6 to 190ee3f Compare March 13, 2023 07:31

snuyanzin reviewed Mar 13, 2023

View reviewed changes

flinkbot added the component=Connectors/Hive label Mar 13, 2023

luoyuxia force-pushed the FLINK-31409 branch 2 times, most recently from ceb3607 to 2b0107c Compare March 13, 2023 12:45

luoyuxia force-pushed the FLINK-31409 branch from 2b0107c to f6ba066 Compare March 20, 2023 02:23

lincoln-lil reviewed Mar 20, 2023

View reviewed changes

luoyuxia force-pushed the FLINK-31409 branch from f6ba066 to db72db1 Compare March 20, 2023 09:09

lincoln-lil approved these changes Mar 21, 2023

View reviewed changes

lincoln-lil self-requested a review March 21, 2023 04:01

luoyuxia force-pushed the FLINK-31409 branch from 7885b0f to f06091f Compare March 21, 2023 04:33

luoyuxia force-pushed the FLINK-31409 branch from f06091f to cf077c2 Compare March 21, 2023 11:13

wuchong reviewed Mar 23, 2023

View reviewed changes

luoyuxia force-pushed the FLINK-31409 branch 2 times, most recently from 636f992 to 7612cca Compare March 24, 2023 09:35

luoyuxia force-pushed the FLINK-31409 branch from 7612cca to ab3c848 Compare March 24, 2023 12:12

wuchong reviewed Apr 23, 2023

View reviewed changes

luoyuxia added 2 commits April 26, 2023 19:20

[FLINK-31409][table] Introduce flink-table-calcite-bridge module

95d1ba9

[FLINK-31409][table] Introduce public interfaces for pluggable dialect

fbe6cea

luoyuxia added 2 commits April 26, 2023 19:20

[FLINK-31409][hive] Hive dialect shouldn't use interfaces in table-pl…

55e15aa

…anner to build LogicPlan

[FLINK-31409][table] Introduce public interfaces for pluggable dialec…

9e508ab

…t: refine interface to address comments

luoyuxia force-pushed the FLINK-31409 branch from ab3c848 to f925bec Compare April 26, 2023 11:37

[FLINK-31409][hive] Hive dialect shouldn't use interfaces in table-pl…

9a53507

…anner to build LogicPlan: address comments

luoyuxia force-pushed the FLINK-31409 branch from f925bec to 9a53507 Compare April 26, 2023 11:39

wuchong approved these changes Apr 26, 2023

View reviewed changes

luoyuxia closed this in f476675 Apr 27, 2023

xishuaidelin pushed a commit to xishuaidelin/flink that referenced this pull request Apr 27, 2023

[FLINK-31409][hive] Hive dialect shouldn't use interfaces in table-pl…

73278d7

…anner to build LogicPlan This closes apache#22166

	* Create the {@link RelOptTable.ToRelContext} used t0 convert a table into a relational
	* Create a new instance of {@link RelOptTable.ToRelContext} used to convert a table into a relational

[FLINK-31409][hive] Hive dialect should use public interfaces #22166

[FLINK-31409][hive] Hive dialect should use public interfaces #22166

Uh oh!

Conversation

luoyuxia commented Mar 13, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What is the purpose of the change

Brief change log

Verifying this change

Does this pull request potentially affect one of the following parts:

Documentation

Uh oh!

flinkbot commented Mar 13, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

CI report:

Uh oh!

Choose a reason for hiding this comment

Uh oh!

luoyuxia commented Mar 17, 2023

Uh oh!

lincoln-lil left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lincoln-lil left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lincoln-lil commented Mar 21, 2023

Uh oh!

luoyuxia commented Mar 21, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

luoyuxia Mar 24, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

luoyuxia commented Mar 24, 2023

Uh oh!

wuchong left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

luoyuxia commented Apr 26, 2023

Uh oh!

luoyuxia commented Apr 26, 2023

Uh oh!

wuchong left a comment

luoyuxia commented Mar 13, 2023 •

edited

Loading

flinkbot commented Mar 13, 2023 •

edited

Loading

luoyuxia Mar 24, 2023 •

edited

Loading