jerryshao commented on PR #10720: URL: https://github.com/apache/gravitino/pull/10720#issuecomment-4350742096
> Two delimiter-governance options are under evaluation @jerryshao Could u give your feedback about this point? > > wo delimiter-governance options are under evaluation: > > * **Option 1 (restricted delimiter set)**: > > * Server only accepts delimiters from a predefined allowed set. > * Delimiter is treated as a reserved hierarchy marker in nested-aware flows. > * Behavior difference for new object creation: > > * Iceberg nested schema creation that uses delimiter as hierarchy path is allowed. > * Hive creation of a non-nested schema name that contains the configured delimiter is rejected > with validation error. > * **Option 2 (unrestricted delimiter)**: > > * Server allows any delimiter value configured by users. > * Compatibility is prioritized for engines that treat schema name as plain string. > * Behavior difference for new object creation: > > * Hive can create a non-nested schema successfully even when the schema name contains the > configured delimiter. > * Nested interpretation is applied only in nested-aware request paths (for example Iceberg > namespace APIs), not as a blanket rule for all engines. I think letting users configure any delimiter they want is more flexible. Defining an allowed list will always have a problem that users want a delimiter other than in the allowed list. From a fresh user's perspective, I think rejection is better than inconsistent behavior between catalogs. Otherwise, they will be confused whether catalog A's behavior is different from catalog B implicitly. From an existing user's perspective, if they already use the delimiter, failing the operation will break their compatibility. If we can add something in the code level to let them explicitly know that this new feature will affect their current usage, I think it is acceptable. Otherwise, mentioning in the doc may not be enough. -- 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]
