rdblue commented on pull request #3275: URL: https://github.com/apache/iceberg/pull/3275#issuecomment-946012151
Previously, a namespace existed if there was a table in that namespace. This changes the definition so that a namespace exists if there is a row in the namespaces table. That is an incompatible definition. I think we need to decide what the behavior should be for the JDBC catalog, and then make sure that the implementation is consistent. If you should be able to implicitly create a namespace by creating a table (as is still allowed) then this needs to return that a namespace exists if a table is in the namespace. On the other hand, if that isn't allowed then `createTable` needs to be updated to check `namespaceExists`. I think that because namespaces have been implicitly created up to now, we should either continue to allow it (for compatibility with existing catalogs) or we should add a property that enables the more strict behavior (probably preferred). Next, it looks like this creates a generic table with catalog name, namespace name, and string blobs. Is that the right way to go? Why not use a `namespace_properties` table that has the schema `catalog string, namespace string, key string, value string`? A namespace would exist if there is a table with the namespace or if there is at least one property for the namespace. That seems like a better way to model the information than converting to and from JSON or base64 to me. What is the benefit of using a row per namespace instead? -- 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]
