markhoerth commented on issue #10521:
URL: https://github.com/apache/gravitino/issues/10521#issuecomment-4122376838

   HI @yuqi1129 and @jerryshao, 
   
   Thanks for digging into this and sharing the code — really helpful to see 
the `EntityCombinedTable` implementation. I want to explain the motivation, 
because I think there's an important distinction worth drawing out.
   
   **The REST API implies this is the intended design.**
   Gravitino exposes `ALTER TABLE SET PROPERTY` as part of its API surface. And 
notably, the current error message is `"Set property is not supported yet"` — 
the word *yet* suggests this was always intended to be built, not excluded by 
design.
   
   **User-defined properties are different from connector properties.**
   Properties like `dbt.model_fqn` or `airflow.dag_id` have no meaning in 
PostgreSQL — they're metadata *about* the table from an external tool's 
perspective, not configuration for the underlying database. Pushing them down 
to PostgreSQL isn't just unsupported, it's the wrong model entirely. These 
properties belong in Gravitino's own metadata layer.
   
   **Gravitino already does this for tags and statistics.**
   Tags and statistics are stored in `tableEntity` — Gravitino's own store — 
not pushed to the underlying catalog. User-defined properties would follow 
exactly the same pattern. Looking at `EntityCombinedTable`, `tableEntity` is 
already right there alongside `table`. The `properties()` method currently 
reads only from `table`, but extending it to also include user-defined 
properties from `tableEntity` would be a natural and consistent addition.
   
   **Why this matters.**
   A key use case for Gravitino is serving as a central metadata layer that 
external tools like dbt, Airflow, and Kubeflow can write back to. Without 
property write-back on JDBC catalogs, that integration pattern is broken for 
some of the most common catalog types in enterprise deployments.
   
   Happy to discuss further — I think this is a valuable feature, and the 
implementation path looks relatively straightforward. The tags and statistics 
implementations in Gravitino's metadata layer could serve as a useful reference 
for how to wire user-defined properties through tableEntity in a consistent way.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to