[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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#4,472 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

@Akeron-Zhu ya está trabajando en esto.

Desde el 2/11/2026.

  • #4474 de @Akeron-Zhu — abierto

Evaluación

Dificultad
1/5
Tiempo estimado
Menos de una hora
Aptitud para principiantes
85/100
Tipo de issue
Documentación
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
markdown
Área
documentation

Línea de trabajo

Actualiza la sección "Configure table properties" en docs/admin-guides/managing-catalogs.md. Lee esa sección y la lógica de backend en CatalogController.constructCatalogMeta() para verificar el comportamiento del prefijo. Hecho significa que el doc indica que el campo dedicado "Table properties" no necesita prefijo table., mientras que el campo crudo "Properties" lo requiere.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
Java
Estrellas
1.2k
Forks
399
Merge medio
4 d 8 h
PR fusionados (30 d)
24

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/amoro

Todos los issues de apache/amoro

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.