[Doc]: Clarify that catalog-level table properties should be added via the "Table properties" interface, and the "table." prefix is only required when using the raw "Properties" interface

オープン 初心者向け
  • 何か問題がありますか？
#4,472 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

@Akeron-Zhu がすでに取り組んでいます。

2026年11月2日 から。

  • #4474 @Akeron-Zhu による — オープン

評価

難易度
1/5
見積もり時間
1時間未満
初心者へのやさしさ
85/100
issue の種類
ドキュメント
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
markdown
領域
documentation

調査の方向性

docs/admin-guides/managing-catalogs.md の "Configure table properties" セクションを更新してください。そのセクションと CatalogController.constructCatalogMeta() のバックエンドロジックを読み、プレフィックスの動作を確認してください。完了とは、ドキュメントが専用の "Table properties" フィールドは table. プレフィックスを必要とせず、生の "Properties" フィールドは必要とすると述べていることです。

索引モデルが issue の本文から書いたものです。

説明

type:improvement
Search before asking
  • I have searched in the issues and found no similar issues.
What would you like to be improved?

The "Configure table properties" section in docs/admin-guides/managing-catalogs.md (added by PR #4358, issue #4357) currently states, in a blanket way, that catalog-level table property keys MUST be prefixed with table..

However, Amoro provides two entry points with different behavior:

  1. The "Table properties" interface (the tableProperties field of CatalogRegisterInfo, i.e. the dedicated "Table properties" field in the AMS UI). The backend automatically prepends table. to every key via PropertiesUtil.unionCatalogProperties() (called from CatalogController.constructCatalogMeta()). So users must NOT write the table. prefix here.

  2. The raw "Properties" interface (the properties field of CatalogRegisterInfo, or the catalog property map directly). Keys are stored as-is, so for a key to act as a table-level default it MUST be manually prefixed with table. (e.g. table.self-optimizing.group).

If a user follows the current doc and adds table. in the "Table properties" field, the backend stores table.table.self-optimizing.group, which is not a valid table property and is silently ignored. The current wording is therefore ambiguous and can lead to the exact misconfiguration it intends to prevent.

On top of that, the current design itself is easy to confuse: users cannot easily tell which keys are table-level properties and which are catalog-level properties just by looking at them, which makes misconfiguration very likely.

How should we improve?

  1. Advise and remind users to configure catalog-level table properties through the dedicated "Table properties" interface (the tableProperties field). There, keys should be entered without the table. prefix, since the backend adds it automatically.

  2. If users must instead use the raw "Properties" interface (the properties field), make it explicit that keys need to be manually prefixed with table.; otherwise the entries will not be recognized as table-level defaults.

  3. Revise the "Configure table properties" section in managing-catalogs.md to reflect the two points above.

Are you willing to submit PR?
  • Yes I am willing to submit a PR!
Subtasks

No response

Code of Conduct
主要言語
Java
スター
1.2k
フォーク
399
平均マージ
4日 8時間
マージ済み PR（30日）
24

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/amoro のほかの issue

apache/amoro の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。