[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

Aperta Adatta ai principianti
  • Qualcosa non va?
#4,472 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@Akeron-Zhu ci sta già lavorando.

Dal 2/11/2026.

  • #4474 di @Akeron-Zhu — aperta

Valutazione

Difficoltà
1/5
Tempo stimato
Meno di un'ora
Idoneità per principianti
85/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
markdown
Ambito
documentation

Direzione di ricerca

Aggiorna la sezione "Configure table properties" in docs/admin-guides/managing-catalogs.md. Leggi quella sezione e la logica backend in CatalogController.constructCatalogMeta() per verificare il comportamento del prefisso. Fatto significa che il doc afferma che il campo dedicato "Table properties" non richiede il prefisso table., mentre il campo grezzo "Properties" lo richiede.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
Lingua principale
Java
Stelle
1.2k
Fork
399
Merge medio
4g 8h
PR unite (30g)
24

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/amoro

Tutte le issue di apache/amoro

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.