Describe the bug
When connecting Wren AI to ClickHouse, columns with Nullable(...) types are not correctly inferred and appear as UNKNOWN in the modelling layer.
Only non-nullable columns (e.g., Int64, String) are correctly detected.
All nullable columns (e.g., Nullable(String), Nullable(Int32)) are shown as UNKNOWN, which makes them unusable in queries and AI analysis.
This results in Wren AI behaving as if the table only has a few columns.
To Reproduce
Connect Wren AI (Docker deployment via official installer) to a ClickHouse database
Use a table with the following schema:
CREATE TABLE dicts.dict_merchant
(
guid_merchant Nullable(Int32),
merchantid Int64,
merchant Nullable(String),
title Nullable(String),
merchant_code Nullable(String),
merchant_city Nullable(String),
uuid_merchant Nullable(String),
merchant_city_code Nullable(String),
address Nullable(String),
merchant_city_1c String
)
ENGINE = MergeTree
ORDER BY merchantid;
Go to Modelling in Wren UI
Select the table dicts.dict_merchant
Observe column types
Expected behavior
merchantid (Int64) → correctly detected (e.g., INT)
merchant_city_1c (String) → correctly detected (VARCHAR)
All columns with Nullable(...) → detected as UNKNOWN
Screenshots
Desktop (please complete the following information):
- OS: Windows
- Browser Chrome
Wren AI Information
WREN_PRODUCT_VERSION=0.29.0
WREN_ENGINE_VERSION=0.21.3
WREN_AI_SERVICE_VERSION=0.29.0
IBIS_SERVER_VERSION=0.21.3
WREN_UI_VERSION=0.31.3
WREN_BOOTSTRAP_VERSION=0.1.5
Additional context
The issue seems isolated specifically to Nullable(...) types in ClickHouse
Non-nullable types are always correctly inferred
The problem persists across multiple tables, not just a single dataset
This behavior makes Wren unusable for typical ClickHouse schemas where nullable columns are common
Relevant log output
- Please share
config.yaml with us, it should be located at ~/.wrenai/config.yaml.
- config.yaml
- Please share your logs with us with the following command:
docker logs wrenai-wren-ui-1 >& wrenai-wren-ui.log
wrenai-wren-ui.log
&&
docker logs wrenai-wren-ai-service-1 >& wrenai-wren-ai-service.log
wrenai-wren-ai-service.log
&&
docker logs wrenai-wren-engine-1 >& wrenai-wren-engine.log
wrenai-wren-engine.log
&&
docker logs wrenai-ibis-server-1 >& wrenai-ibis-server.log
wrenai-ibis-server.log
Describe the bug
When connecting Wren AI to ClickHouse, columns with Nullable(...) types are not correctly inferred and appear as UNKNOWN in the modelling layer.
Only non-nullable columns (e.g., Int64, String) are correctly detected.
All nullable columns (e.g., Nullable(String), Nullable(Int32)) are shown as UNKNOWN, which makes them unusable in queries and AI analysis.
This results in Wren AI behaving as if the table only has a few columns.
To Reproduce
Connect Wren AI (Docker deployment via official installer) to a ClickHouse database
Use a table with the following schema:
CREATE TABLE dicts.dict_merchant
(
guid_merchant Nullable(Int32),
merchantid Int64,
merchant Nullable(String),
title Nullable(String),
merchant_code Nullable(String),
merchant_city Nullable(String),
uuid_merchant Nullable(String),
merchant_city_code Nullable(String),
address Nullable(String),
merchant_city_1c String
)
ENGINE = MergeTree
ORDER BY merchantid;
Go to Modelling in Wren UI
Select the table dicts.dict_merchant
Observe column types
Expected behavior
merchantid (Int64) → correctly detected (e.g., INT)
merchant_city_1c (String) → correctly detected (VARCHAR)
All columns with Nullable(...) → detected as UNKNOWN
Screenshots
Desktop (please complete the following information):
Wren AI Information
WREN_PRODUCT_VERSION=0.29.0
WREN_ENGINE_VERSION=0.21.3
WREN_AI_SERVICE_VERSION=0.29.0
IBIS_SERVER_VERSION=0.21.3
WREN_UI_VERSION=0.31.3
WREN_BOOTSTRAP_VERSION=0.1.5
Additional context
The issue seems isolated specifically to Nullable(...) types in ClickHouse
Non-nullable types are always correctly inferred
The problem persists across multiple tables, not just a single dataset
This behavior makes Wren unusable for typical ClickHouse schemas where nullable columns are common
Relevant log output
config.yamlwith us, it should be located at~/.wrenai/config.yaml.docker logs wrenai-wren-ui-1 >& wrenai-wren-ui.logwrenai-wren-ui.log
&&
docker logs wrenai-wren-ai-service-1 >& wrenai-wren-ai-service.log
wrenai-wren-ai-service.log
&&
docker logs wrenai-wren-engine-1 >& wrenai-wren-engine.log
wrenai-wren-engine.log
&&
docker logs wrenai-ibis-server-1 >& wrenai-ibis-server.log
wrenai-ibis-server.log