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

   ### What would you like to be improved?
   
   Gravitino should provide a lightweight table metadata probing interface for 
use cases that do not need full table schema loading.
   
   Currently, Gravitino REST and Lance REST share the same  path. This creates 
a coupling problem:
   
   - Gravitino REST wants to show the latest table schema, so  may reasonably 
trigger schema loading or schema repair from the underlying storage.
   - Lance REST  is often used as a lightweight probe. In most cases it only 
needs location, table properties, and storage options, especially when .
   
   Because both paths use the same  method, improving Gravitino REST schema 
correctness can unintentionally make Lance REST lightweight describe requests 
open the underlying Lance dataset and refresh/write Gravitino table columns.
   
   This is the main issue: a full schema-loading API and a lightweight 
metadata-probing API are currently the same operation.
   
   ### How should we improve?
   
   Add a lightweight table metadata probing interface in Gravitino.
   
   This interface should let callers fetch basic table metadata, such as 
location/properties/storage options, without triggering schema loading, 
underlying storage access, or lazy schema repair.
   
   Lance REST  can use this lightweight probing path, while Gravitino REST and 
detailed Lance REST requests can continue using the full table loading path 
when schema information is required.


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