fanruan-tuco opened a new issue, #18059: URL: https://github.com/apache/iceberg/issues/18059
### Query engine None — custom catalog implementation backed by FoundationDB ### Question I am implementing a FoundationDB-backed catalog and would like to clarify the concurrency contract of `SupportsNamespaces.dropNamespace` before choosing the implementation semantics. The current Javadoc says that the method drops a namespace, returns `true` if it was dropped, and may throw `NamespaceNotEmptyException` when the namespace is not empty. It does not state whether checking emptiness and deleting the namespace must be atomic with respect to concurrent catalog operations. For example: 1. `dropNamespace(ns)` observes no child namespaces, tables, views, or other objects. 2. A concurrent `createTable(ns.table)` commits successfully. 3. `dropNamespace(ns)` deletes the namespace and returns `true`. Should the API require behavior equivalent to a linearizable conditional delete? In the example above, I would expect either the drop to linearize first and the concurrent create to fail, or the create to linearize first and the drop to fail with `NamespaceNotEmptyException`. A successful drop should not invalidate or orphan an object that committed before the drop. Built-in implementations appear to provide different levels of protection: - `InMemoryCatalog` checks children, tables, and views under the same monitor. - Nessie performs a commit and maps a server-side `NAMESPACE_NOT_EMPTY` conflict. - Hive and BigQuery delegate restricted deletion to one backend operation. - JDBC, Glue, DynamoDB, and ECS perform separate list/check and delete operations. - The REST specification says only that the namespace must be empty. Would it make sense to clarify the Java API and REST specification with the following points? - What counts as non-empty, including child namespaces and supported catalog objects. - Whether emptiness validation and deletion MUST be atomic, or otherwise provide equivalent linearizable behavior, relative to concurrent creates and renames into the namespace. - If atomic behavior is not required, what minimum behavior catalog implementations and callers may rely on. FoundationDB can perform the emptiness check and namespace deletion in one serializable transaction, and that is the behavior I currently plan to implement. I would like to confirm whether this is required by the API, recommended as a stronger implementation guarantee, or intentionally left implementation-specific. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
