roryqi opened a new pull request, #11318:
URL: https://github.com/apache/gravitino/pull/11318

   ### What changes were proposed in this pull request?
   
   Default the Iceberg `jdbc.strict-mode` property to `true` for the JDBC 
catalog backend, in `IcebergCatalogUtil#loadJdbcCatalog` (via `putIfAbsent`, 
mirroring the existing `jdbc.schema-version` default). The value can still be 
overridden by an explicit config.
   
   ### Why are the changes needed?
   
   The JDBC backend implicitly created the namespace when a table (or view) was 
created under a non-existent namespace, returning `200 OK` instead of the HTTP 
`404 NoSuchNamespaceError` required by the Iceberg REST catalog spec. The 
memory backend already returns 404. This caused namespace proliferation, hid 
namespace-name typos, and was spec-non-compliant. With strict mode, 
`JdbcTableOperations`/`JdbcViewOperations` validate namespace existence before 
commit and throw `NoSuchNamespaceException`.
   
   Fix: #11285
   
   ### Does this PR introduce _any_ user-facing change?
   
   Yes. For the Iceberg REST service backed by the JDBC catalog, creating a 
table or view in a namespace that does not exist now fails with HTTP 404 
instead of implicitly creating the namespace. Operators relying on the old 
implicit behavior can restore it by explicitly setting 
`gravitino.iceberg-rest.jdbc.strict-mode = false`. No property keys were added 
or removed (the property is provided by Iceberg).
   
   ### How was this patch tested?
   
   - Unit tests in `TestIcebergCatalogUtil`: default strict mode rejects 
creating a table in a missing namespace with `NoSuchNamespaceException`; an 
explicit `jdbc.strict-mode=false` is not overridden and allows implicit 
creation.
   - Integration test 
`IcebergRESTServiceIT#testCreateTableInNonExistentNamespace` exercises the 
end-to-end REST path and runs across the memory, hive, and JDBC backends.


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