yuqi1129 opened a new issue, #13931: URL: https://github.com/apache/gravitino/issues/13931
### Version main branch ### Describe what's wrong Registering an existing Lance dataset through the Gravitino table API with `format=lance` and `lance.register=true` stores the table as managed unless the caller also sets `external=true`. A later ordinary `dropTable` deletes the existing dataset even though registration only created catalog metadata. The documented registration examples omit `external`, while the Lance REST register path already forces it to true. Existing incorrectly classified registrations are also at risk during drop or registration overwrite. ### Error message and/or stacktrace No error is required: drop succeeds and removes the dataset. ### How to reproduce 1. Create a temporary Lance dataset outside Gravitino. 2. Register its location through the Gravitino create-table API with `format=lance` and `lance.register=true`, omitting `external`. 3. Drop the registered table through the Gravitino table API. 4. The dataset is deleted instead of only removing catalog metadata. Supplying `external=false` has the same result. ### Additional context Registration should imply external ownership. Ordinary drop, schema cascade and Lance REST deregistration must preserve registered data, including older records with a missing or false external flag. Location-provider reclamation must follow the same ownership decision. Explicit purge and Lance REST drop should retain their existing data-deletion semantics. -- 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]
