jerryshao opened a new issue, #13317:
URL: https://github.com/apache/gravitino/issues/13317

   ### What would you like to be improved?
   
   #13312 validates the reported names, aliases and comments before they are 
written to the entity store, and maps value-too-long SQL errors to a 400 
without the database message. The following gaps remain, ordered by likely 
impact.
   
   **1. Loading a Kafka topic whose name is longer than 128 characters fails 
with 500**
   
   Kafka allows topic names up to 249 characters, but `topic_meta.topic_name` 
is `VARCHAR(128)`. `TopicOperationDispatcher#loadTopic` imports externally 
created topics into the store. When `store.put` fails, `importTopic` wraps the 
error in a `RuntimeException`, so loading such a topic returns 500.
   
   **2. Entity store failures are swallowed on view and topic 
creation/alteration**
   
   `ViewOperationDispatcher#createView` and 
`TopicOperationDispatcher#createTopic` / `alterTopic` catch every exception 
from the entity store write and only log it. The object is created or altered 
in the external system, the request succeeds, and the Gravitino entity is 
silently missing or stale. This applies to any store failure, not only length 
violations.
   
   **3. View `default_catalog` / `default_schema` are not validated**
   
   Both are `VARCHAR(128)` and user supplied. A longer value is currently lost 
through the swallowed failure in (2).
   
   **4. Column widths differ between backends**
   
   `fileset_version_info.storage_location_name` and 
`model_version_info.model_version_uri_name` are `VARCHAR(128)` in H2 but 
`VARCHAR(256)` in MySQL and PostgreSQL. The same request is accepted on one 
backend and rejected on another.
   
   **5. Remaining columns only covered by the generic fallback**
   
   Column comments (`VARCHAR(4096)`), fileset location names and model version 
URI names get the generic "exceeds the maximum length of its column" 400 
instead of a message naming the field and limit.
   
   **6. Principal names longer than 128 characters leave a metalake half 
created**
   
   `MetalakeHookDispatcher#createMetalake` commits the metalake before adding 
the creator as a user. If the principal name is longer than the `user_name` 
column, the user insert fails after the metalake already exists.
   
   ### How should we improve?
   
   1. Validate topic names during import, or widen `topic_name` to match 
Kafka's limit, and return a proper error instead of a 500.
   2. Stop swallowing entity store failures on view and topic writes. Either 
surface the error, or roll back the external object so the two stay consistent.
   3. Validate view `default_catalog` / `default_schema` in 
`ViewNormalizeDispatcher` before the view is created externally.
   4. Align the widths of `storage_location_name` and `model_version_uri_name` 
across all backends through an upgrade script, then add `EntityFieldLimits` 
checks for them.
   5. Add field-level limits for the remaining columns so every error names the 
field and limit.
   6. Validate the principal name before the metalake is created, or create the 
metalake and its owner user in one transaction.
   


-- 
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