This is an automated email from the ASF dual-hosted git repository.
voonhous pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/hudi.git
The following commit(s) were added to refs/heads/asf-site by this push:
new c35b4c793dfc docs(troubleshooting): note that a plain set only reaches
an embedded metastore (#19554)
c35b4c793dfc is described below
commit c35b4c793dfc5054419abd0335a72f612d9113e8
Author: deepakpanda93 <[email protected]>
AuthorDate: Fri Aug 14 21:33:35 2026 +0530
docs(troubleshooting): note that a plain set only reaches an embedded
metastore (#19554)
* docs(troubleshooting): note that a plain set only reaches an embedded
metastore
The Hive Sync entry for "The following columns have types incompatible with
the existing columns in their respective positions" recommends
set hive.metastore.disallow.incompatible.col.type.changes=false;
but that statement writes only to the session HiveConf. SetProcessor routes
a
variable to Hive#setMetaConf -> IMetaStoreClient#setMetaConf only when it
carries the metaconf: prefix, and HiveAlterHandler#alterTable evaluates the
check against handler.getConf(), the metastore's own configuration. Against
a
remote metastore the recommended set therefore has no effect and the error
persists.
Keep the existing advice, which is correct for an embedded metastore, and
add
the two options that work against a remote Hive metastore service: the
server's hive-site.xml, or a per-connection metaconf: override. The property
is a metaConfVars entry, so the server accepts the override.
Applied to next and to version-1.2.0, the current released docs.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
* docs(troubleshooting): scope the metaconf: override to Beeline
Testing the guidance against Hive 3.1.3 showed the metaconf: form is not
universal across Hive clients.
Over HiveServer2 (Beeline) it works: `set metaconf:...=false` followed by
`ALTER TABLE ... REPLACE COLUMNS` succeeded, taking the table from
(id, name, ts) to (id, age, name, ts).
The legacy Hive CLI is different. It does reach the metastore -- reading the
value back with `set metaconf:<key>` returns false where it returned true
before -- but the subsequent ALTER is still rejected with "The following
columns have types incompatible with the existing columns in their
respective
positions", because the connection that runs the DDL is not the one carrying
the override. A plain `set` fails on both clients, as already documented.
Name Beeline explicitly and point Hive CLI users at the hive-site.xml
option.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
---------
Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
---
website/docs/troubleshooting.md | 14 +++++++++++++-
website/versioned_docs/version-1.2.0/troubleshooting.md | 14 +++++++++++++-
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/website/docs/troubleshooting.md b/website/docs/troubleshooting.md
index 4a064d9b1cb7..dbee7cbd9ad3 100644
--- a/website/docs/troubleshooting.md
+++ b/website/docs/troubleshooting.md
@@ -3,7 +3,7 @@ title: Troubleshooting
keywords: [hudi, troubleshooting]
toc_min_heading_level: 2
toc_max_heading_level: 5
-last_modified_at: 2021-08-18T15:59:57-04:00
+last_modified_at: 2026-08-06T11:50:06+05:30
---
For performance related issues, please refer to the [tuning
guide](https://hudi.apache.org/docs/tuning-guide)
@@ -188,6 +188,18 @@ This will usually happen when you are trying to add a new
column to existing hiv
set hive.metastore.disallow.incompatible.col.type.changes=false;
```
+The metastore evaluates this check against its own configuration, so the `set`
above only takes effect when the
+metastore is embedded in the same session. Against a remote Hive metastore
service, either set the property in the
+metastore's `hive-site.xml` and restart the service, or override it for a
single Beeline session with the `metaconf:`
+prefix, which pushes the value to the metastore for that connection:
+
+```sql
+set metaconf:hive.metastore.disallow.incompatible.col.type.changes=false;
+```
+
+The `metaconf:` form applies over HiveServer2. The legacy Hive CLI sends the
value to the metastore but does not apply it
+to the connection that runs the `ALTER`, so use the `hive-site.xml` option
there.
+
#### HoodieHiveSyncException: Could not convert field Type from `<type1>` to
`<type2>` for field col1
This occurs because HiveSyncTool currently supports only few compatible data
type conversions. Doing any other incompatible change will throw this
exception. Please check the data type evolution for the concerned field and
verify if it indeed can be considered as a valid data type conversion as per
Hudi code base.
diff --git a/website/versioned_docs/version-1.2.0/troubleshooting.md
b/website/versioned_docs/version-1.2.0/troubleshooting.md
index 4a064d9b1cb7..dbee7cbd9ad3 100644
--- a/website/versioned_docs/version-1.2.0/troubleshooting.md
+++ b/website/versioned_docs/version-1.2.0/troubleshooting.md
@@ -3,7 +3,7 @@ title: Troubleshooting
keywords: [hudi, troubleshooting]
toc_min_heading_level: 2
toc_max_heading_level: 5
-last_modified_at: 2021-08-18T15:59:57-04:00
+last_modified_at: 2026-08-06T11:50:06+05:30
---
For performance related issues, please refer to the [tuning
guide](https://hudi.apache.org/docs/tuning-guide)
@@ -188,6 +188,18 @@ This will usually happen when you are trying to add a new
column to existing hiv
set hive.metastore.disallow.incompatible.col.type.changes=false;
```
+The metastore evaluates this check against its own configuration, so the `set`
above only takes effect when the
+metastore is embedded in the same session. Against a remote Hive metastore
service, either set the property in the
+metastore's `hive-site.xml` and restart the service, or override it for a
single Beeline session with the `metaconf:`
+prefix, which pushes the value to the metastore for that connection:
+
+```sql
+set metaconf:hive.metastore.disallow.incompatible.col.type.changes=false;
+```
+
+The `metaconf:` form applies over HiveServer2. The legacy Hive CLI sends the
value to the metastore but does not apply it
+to the connection that runs the `ALTER`, so use the `hive-site.xml` option
there.
+
#### HoodieHiveSyncException: Could not convert field Type from `<type1>` to
`<type2>` for field col1
This occurs because HiveSyncTool currently supports only few compatible data
type conversions. Doing any other incompatible change will throw this
exception. Please check the data type evolution for the concerned field and
verify if it indeed can be considered as a valid data type conversion as per
Hudi code base.