Skip to content

HIVE-29241: Distinguish the default location of the database by catalog#6267

Open
zhangbutao wants to merge 1 commit intoapache:masterfrom
zhangbutao:HIVE-29241_LOCATION
Open

HIVE-29241: Distinguish the default location of the database by catalog#6267
zhangbutao wants to merge 1 commit intoapache:masterfrom
zhangbutao:HIVE-29241_LOCATION

Conversation

@zhangbutao
Copy link
Copy Markdown
Contributor

@zhangbutao zhangbutao commented Jan 14, 2026

What changes were proposed in this pull request?

The main objectives of this PR are:

  1. Allow location to be omitted when creating a catalog. At the same time, it is necessary to determine catalogs that do not require a location, such as JDBC catalogs.

  2. For newly created catalogs, the location of their databases will be determined by the two newly added parameters: metastore.warehouse.catalog.dir and metastore.warehouse.catalog.external.dir. This helps better ensure that the location of the default Hive catalog's databases and tables remains unaffected.

For example, if metastore.warehouse.catalog.dir is hdfs://ns1/testdir, then the location for a newly created catalog named testcat would be hdfs://ns1/testdir/testcat. Consequently, the default path for a database like testdb created under this catalog would be hdfs://ns1/testdir/testcat/testdb.

  1. Modify the semantics of catalog creation. The type parameter must be specified when creating a catalog to distinguish its type. Based on this type, it will be determined whether the catalog's databases and tables require a location, or whether the catalog type supports creating databases and tables.
    CREATE CATALOG test_cat COMMENT 'Hive test catalog' PROPERTIES('type'='NATIVE');

Why are the changes needed?

The paths of databases and tables created under a non-default catalog may interfere with those under the default Hive catalog. We need to introduce parameters to distinguish the paths for databases and tables under non-default catalogs, ensuring that the paths of the default Hive catalog remain unaffected.

Does this PR introduce any user-facing change?

No

How was this patch tested?

Existing tests.

Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This pull request introduces catalog-aware warehouse paths for Hive metastore, allowing databases and tables under non-default catalogs to have distinct storage locations. The changes ensure that catalog locations are properly isolated while maintaining backward compatibility for the default Hive catalog.

Changes:

  • Added new configuration parameters (WAREHOUSE_CATALOG and WAREHOUSE_CATALOG_EXTERNAL) for catalog-specific warehouse directories
  • Modified catalog creation to require a 'type' parameter and made location optional with automatic defaults
  • Updated database path resolution throughout the codebase to use catalog-aware logic via new Warehouse methods that accept catalog names

Reviewed changes

Copilot reviewed 23 out of 23 changed files in this pull request and generated 21 comments.

Show a summary per file
File Description
MetastoreConf.java Added WAREHOUSE_CATALOG and WAREHOUSE_CATALOG_EXTERNAL configuration variables
HiveConf.java Added corresponding Hive configuration variables for catalog warehouses
Warehouse.java Enhanced path resolution methods to accept catalog names; added deprecated markers for old methods
CatalogUtil.java New utility class for catalog type validation (NATIVE, ICEBERG)
CreateCatalogAnalyzer.java Updated to validate catalog type property and make location optional
CreateCatalogOperation.java Modified to generate default location from WAREHOUSE_CATALOG config
CreateDatabaseAnalyzer.java Added validation to check if catalog supports database creation
CreateDatabaseOperation.java Updated path building logic to include catalog names for non-default catalogs
DDLUtils.java Added helper method to check catalog support for database creation
HiveParser.g Modified grammar to make catalog location optional and properties required
EximUtil.java Updated to use catalog-aware warehouse paths for replication
Multiple test files Updated test queries to include required 'type' property in CREATE CATALOG statements
HMSHandler.java Updated default catalog and database creation to use catalog-aware paths
MetastoreDefaultTransformer.java Updated to pass Database object instead of just name
Migration/Authorization files Updated to use new Database-based path methods

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 28 out of 28 changed files in this pull request and generated 9 comments.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@dengzhhu653
Copy link
Copy Markdown
Member

Yes. Users can specify different locations for native catalogs; if a user does not specify a location for a native catalog, the default value will be used.

This could make some confusing. For example, we declare a S3 catalog but the location is absent, then this catalog is created with a hdfs location, some databases without explicit location will be put under the hdfs, while some are on the cloud, it might be a problem if we use the FileSystem created by the catalog's properties to operate against these tables or databases.

In HMS, we can enforce the location check when creating the catalog, if it's null and the catalog is native, then we should throw the exception.

@zhangbutao
Copy link
Copy Markdown
Contributor Author

This could make some confusing. For example, we declare a S3 catalog but the location is absent, then this catalog is created with a hdfs location, some databases without explicit location will be put under the hdfs, while some are on the cloud, it might be a problem if we use the FileSystem created by the catalog's properties to operate against these tables or databases.

In HMS, we can enforce the location check when creating the catalog, if it's null and the catalog is native, then we should throw the exception.

I understand what you mean. I think what we're discussing is more about usage habits.

Before the catalog capability was available, Hive used databases as a way to isolate data, and when users created a Hive database, they could omit the location, in which case the database would use the default location. If users wanted to set a value different from the default catalog location, they could specify a specific location, such as an S3 location, when creating the catalog.

This syntax of omiting the location is more flexible, and I think users might be more accustomed to the usage of having a default catalog location.

I would also like to hear other folks' thoughts on the default catalog location. :)

@deniskuzZ
Copy link
Copy Markdown
Member

deniskuzZ commented Apr 7, 2026

i'm ok with default catalog location for native catalogs if not explicitly provided

@deniskuzZ
Copy link
Copy Markdown
Member

deniskuzZ commented Apr 7, 2026

hi @zhangbutao, is the PR ready for 2nd round of review and includes the changes we discussed here?

@zhangbutao
Copy link
Copy Markdown
Contributor Author

One thing to note: Currently, we have two entry points for creating catalogs—one is the SQL-based catalog creation entry involved in this PR, and the other is the HMS API-based catalog creation entry. In this PR, I intend to enforce the inclusion of the type attribute when users create catalogs via SQL, so that users can clearly distinguish between different types of catalogs. However, the HMS API side does not enforce the type attribute when creating catalogs, which would lead to inconsistency between the two entry points.
Therefore, I have two approaches to resolve this issue and ensure consistency between the two entry points:

  1. On the HMS server side, specifically in the HMSHandler, enforce a check during catalog creation to verify whether the user has provided the type attribute. If the type is missing, return an error. This approach would introduce backward compatibility issues for catalog creation.
  2. Modify the current PR to make the type attribute optional for SQL-based catalog creation. For both SQL-based catalog creation and HMS API-based catalog creation, if the user does not provide the type attribute, assign a default value (e.g., native) on the HMSHandler server side. This approach would not cause compatibility issues with the catalog creation syntax. However, other open-source components enforce the type attribute requirement, and the type helps users better understand the parameter requirements for the catalog, among other benefits.

What are your suggestions regarding these two approaches? Thanks in advance. cc @deniskuzZ @difin

@zhangbutao i would vote for option 2, fallback to default - native

Changes have been made to keep the type optional when creating a catalog. Thanks for the advice.

@zhangbutao
Copy link
Copy Markdown
Contributor Author

hi @zhangbutao, is the PR ready for 2nd round of review and includes the changes we discussed here?

Let's go :)

// Create a fake fs root for local fs
Path localFsRoot = new Path(path, "localfs");
warehousePath = new Path(localFsRoot, "warehouse");
warehouseCatPath = new Path(localFsRoot, "catalog");
Copy link
Copy Markdown
Member

@deniskuzZ deniskuzZ Apr 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't the catalog be under the warehousePath?

Warehouse Root
  └── Catalog (default or named)
        └── Database (.db)
              └── Table

/warehouse/<catalog_name>/<database_name>.db/<table_name>/   # non default catalog
/warehouse/hive/<database_name>.db/<table_name>/             # default catalog
/warehouse/hive/default.db/<table_name>/                     # default catalog & database


// Initialize props if null, and set default type to native if not specified
if (props == null) {
props = new HashMap<>();
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we do this in the var initialization?

}

private static void checkCatalogType(Map<String, String> props) throws SemanticException {
String catalogType = props.get("type");
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we please create constant for that

}
// Normalize and validate catalog type (fail fast on invalid input)
try {
props.put("type", CatalogUtil.normalizeCatalogType(catalogType));
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we simplify by handling isNullOrEmpty in normalizeCatalogType

@Override
public int execute() throws Exception {
Catalog catalog = new Catalog(desc.getName(), desc.getLocationUri());
String catLocationUri = Optional.ofNullable(desc.getLocationUri())
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor. i think cat prefix in local var is redundant here since we are inside CreateCatalog class

@@ -51,10 +52,9 @@ public CreateDatabaseAnalyzer(QueryState queryState) throws SemanticException {
@Override
public void analyzeInternal(ASTNode root) throws SemanticException {
Pair<String, String> catDbNamePair = DDLUtils.getCatDbNamePair((ASTNode) root.getChild(0));
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about record CatalogDb(String catalog, String database) {}
please see #6379 (comment)

}

private void makeLocationQualified(Database database) throws HiveException {
String catalogName = database.getCatalogName().toLowerCase();
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't the names be normalized here: special chars/encoding lowercase?

private void makeLocationQualified(Database database) throws HiveException {
String catalogName = database.getCatalogName().toLowerCase();
String dbName = database.getName().toLowerCase();
boolean isDefaultCatalog = Warehouse.DEFAULT_CATALOG_NAME.equalsIgnoreCase(catalogName);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

consider moving to utils


// managed warehouse root
String whManagedLocatoion = MetastoreConf.getVar(conf,
isDefaultCatalog ? MetastoreConf.ConfVars.WAREHOUSE
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please see #6267 (comment)

if (db == null) {
LOG.warn("Database ({}) for query history table hasn't been found, auto-creating one", QUERY_HISTORY_DB_NAME);
String location = getDatabaseLocation(QUERY_HISTORY_DB_NAME);
db = new Database();
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks a bit weird creating 2 Database objects in same method

Path root = null;
try {
initWh();
// TODO catalog. Need to determine auth root path based on catalog name.
Copy link
Copy Markdown
Member

@deniskuzZ deniskuzZ Apr 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you please add the ticket to the EPIC
cc @saihemanth-cloudera, as he is the most experienced in this area

set hive.support.concurrency=true;

CREATE CATALOG testcat LOCATION '/tmp/testcat' COMMENT 'Hive test catalog';
CREATE CATALOG testcat LOCATION '/tmp/testcat' COMMENT 'Hive test catalog' PROPERTIES('type'='native');
Copy link
Copy Markdown
Member

@deniskuzZ deniskuzZ Apr 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is redundant

-- CREATE with comment
CREATE CATALOG test_cat LOCATION 'hdfs:///tmp/test_cat' COMMENT 'Hive test catalog';
-- CREATE with comment and default location
CREATE CATALOG test_cat COMMENT 'Hive test catalog' PROPERTIES('type'='NATIVE');
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same 'type'='NATIVE' is redundant


-- CREATE INE already exists
CREATE CATALOG IF NOT EXISTS test_cat LOCATION 'hdfs:///tmp/test_cat';
CREATE CATALOG IF NOT EXISTS test_cat LOCATION 'hdfs:///tmp/test_cat' PROPERTIES('type'='native');
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we have tests for external catalog?


public class CatalogUtil {
// Catalog type constants
public static final String NATIVE = "native";
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no need for Strings, please use enum values.

FileSystem cmFs = cmroot.getFileSystem(conf);
cmFs.setPermission(cmroot, new FsPermission("770"));
try {
// TODO catalog. The Repl function is currently only available for the default catalog path ConfVars.WAREHOUSE.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we add the ticket to the EPIC?

}

whRootString = getRequiredVar(conf, ConfVars.WAREHOUSE);
whCatRootString = getRequiredVar(conf, ConfVars.WAREHOUSE_CATALOG);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please see the comment on default FS structure

return getWhRoot();
}
return new Path(getWhRoot(), dbName.toLowerCase() + DATABASE_WAREHOUSE_SUFFIX);
Database db = new Database();
Copy link
Copy Markdown
Member

@deniskuzZ deniskuzZ Apr 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are you using Database only as a DTO object? instead you could use a record CatalogDb as mentioned earlier

if (configUri != null && !configUri.isEmpty()) {
properties.put("uri", configUri);
}
// TODO catalog. Consider adding new created native catalog warehouse(MetastoreConf.ConfVars.WAREHOUSE_CATALOG) later.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you please elaborate, i don't quite get what you are suggesting here

@sonarqubecloud
Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants