Search before asking
Version
master (reproduced on the ~2026-08-16 tip, b9ee837)
What's Wrong?
After the external-catalog connector refactor (#64304 line), selecting any column whose name contains an uppercase letter from an external Iceberg table fails:
ERROR 1105 (HY000): errCode = 2, detailMessage = [INTERNAL_ERROR]schema mapping is missing
projected column 'channelId'; the schema info from FE is inconsistent with the scan projection (file: ...)
Plain scalar columns fail the same way as complex ones — any camelCase name is enough. All-lowercase columns read fine.
Root cause, from tracing it in production: IcebergSchemaUtils.buildCurrentSchema (fe-connector-iceberg) keys the current-schema (-1) dictionary's top-level TField names off the lowercased requested names (IcebergScanPlanProvider.requestedLowerNames — the column handles are already lowercased). But the BE scan slot names preserve the Iceberg column case, and ParquetReader::_do_init_reader (the "schema mapping is missing projected column" guard) compares slot names against the dictionary verbatim. So the dict says channelid, the slot says channelId, and the guard refuses. The doc comment on requestedLowerNames asserts the dict names equal the BE scan-slot names "by construction" — that only holds for tables whose columns are already lowercase. The pre-refactor fe-core path built this dictionary from the Doris Column names (real case, ExternalUtil), which is why the same tables read fine before the decoupling.
What You Expected?
Column reads work regardless of name case, as they did via the legacy fe-core Iceberg path.
How to Reproduce?
- Any external Iceberg table (REST catalog in my case) with a column like
channelId STRING.
SELECT channelId FROM cat.db.t LIMIT 1; → the error above. A lowercase sibling column on the same table reads fine.
Anything Else?
Hit this while rebasing our production build onto master — MongoDB-derived lakehouse tables are almost entirely camelCase, so every one of them was unreadable. We're running a fix in production: emit the schema's own field case for the dictionary's top-level names and keep the lowered name only as the caseInsensitiveFindField lookup key (the equality-delete carrier can stay lowercased — it's consumed strictly by field id).
Are you willing to submit PR?
Code of Conduct
Search before asking
Version
master (reproduced on the ~2026-08-16 tip, b9ee837)
What's Wrong?
After the external-catalog connector refactor (#64304 line), selecting any column whose name contains an uppercase letter from an external Iceberg table fails:
Plain scalar columns fail the same way as complex ones — any camelCase name is enough. All-lowercase columns read fine.
Root cause, from tracing it in production:
IcebergSchemaUtils.buildCurrentSchema(fe-connector-iceberg) keys the current-schema (-1) dictionary's top-level TField names off the lowercased requested names (IcebergScanPlanProvider.requestedLowerNames— the column handles are already lowercased). But the BE scan slot names preserve the Iceberg column case, andParquetReader::_do_init_reader(the "schema mapping is missing projected column" guard) compares slot names against the dictionary verbatim. So the dict sayschannelid, the slot sayschannelId, and the guard refuses. The doc comment onrequestedLowerNamesasserts the dict names equal the BE scan-slot names "by construction" — that only holds for tables whose columns are already lowercase. The pre-refactor fe-core path built this dictionary from the DorisColumnnames (real case,ExternalUtil), which is why the same tables read fine before the decoupling.What You Expected?
Column reads work regardless of name case, as they did via the legacy fe-core Iceberg path.
How to Reproduce?
channelId STRING.SELECT channelId FROM cat.db.t LIMIT 1;→ the error above. A lowercase sibling column on the same table reads fine.Anything Else?
Hit this while rebasing our production build onto master — MongoDB-derived lakehouse tables are almost entirely camelCase, so every one of them was unreadable. We're running a fix in production: emit the schema's own field case for the dictionary's top-level names and keep the lowered name only as the
caseInsensitiveFindFieldlookup key (the equality-delete carrier can stay lowercased — it's consumed strictly by field id).Are you willing to submit PR?
Code of Conduct