This new behavior—where explicitly specifying the catalog name is now required and the absence of the catalog triggers an error—suggests a change or stricter validation in Databricks' handling of schema creation, especially when interacting with the "hive_metastore" catalog via RPC or Java API. Previously, omitting the catalog assumed the default as "hive_metastore," but now Databricks expects this parameter to be provided explicitly.
Expected Behavior or Regression?
Recent updates to Databricks have increased the strictness around catalog and schema management APIs, enforcing explicit specification of parameters that were previously defaulted or inferred. This means that not providing the catalog name—resulting in an empty string—now leads to an error like the one you encountered:
Invalid input: RPC CreateSchema Field managedcatalog.SchemaInfo.catalog_name: name "" is not a valid name
Such changes are typically part of efforts to standardize and future-proof the platform, which is adding native catalog support beyond "hive_metastore." As a result, ambiguity about the catalog is being resolved by enforcing explicit naming.
Actions and Recommendations
-
Immediate solution: Continue specifying the "hive_metastore" catalog in the Java code as a workaround. This aligns with current platform requirements.
-
Long-term: Review Databricks release notes and changelogs for platform, API, or schema management changes related to catalog handling. Sometimes these changes are documented as breaking changes or enhancements affecting production deployments.
-
Best practice: Always specify catalog explicitly when programmatically managing schemas—especially in multi-catalog, multi-workspace, or newer platform versions.
Summary Table
Previous Behavior |
Current Behavior |
Recommended Fix |
Catalog defaulted to "hive_metastore" |
Explicit catalog required |
Specify "hive_metastore" in code |
This change is likely expected behavior rather than a regression, resulting from evolving API and platform standards in Databricks. If the code must remain unchanged due to deployment constraints, consider reaching out to Databricks support and review recent documentation for configuration flags or backward compatibility options.
If further clarification is needed, consult recent Databricks documentation or contact Databricks support with the exact error and API usage pattern.