ClickHouseClient._verify_database_supports_exchange() accepts only the Atomic and Shared database engines. My managed ClickHouse (v25.3.14) creates databases with the Replicated engine, so staging-optimized is rejected there.
My understanding is that Replicated is built on top of Atomic and also supports EXCHANGE TABLES. It does work when I try it by hand:
CREATE TABLE db.a (x Int8) ENGINE = MergeTree ORDER BY x;
CREATE TABLE db.b (x Int8) ENGINE = MergeTree ORDER BY x;
EXCHANGE TABLES db.a AND db.b; -- works
Am I missing a reason why Replicated is excluded (some edge case with replicated DDL, cloud variants, older ClickHouse versions...)? If not, would you accept adding it to the allowed engines?
Workaround
Meanwhile I bypass the probe like this, and loads run fine (atomic swaps, readers never see empty tables):
ClickHouseClient._verify_database_supports_exchange = lambda self: None
Is this safe to keep in production, or is there a subtlety that makes the guard stricter on purpose?
ClickHouseClient._verify_database_supports_exchange()accepts only theAtomicandShareddatabase engines. My managed ClickHouse (v25.3.14) creates databases with theReplicatedengine, sostaging-optimizedis rejected there.My understanding is that
Replicatedis built on top ofAtomicand also supportsEXCHANGE TABLES. It does work when I try it by hand:Am I missing a reason why
Replicatedis excluded (some edge case with replicated DDL, cloud variants, older ClickHouse versions...)? If not, would you accept adding it to the allowed engines?Workaround
Meanwhile I bypass the probe like this, and loads run fine (atomic swaps, readers never see empty tables):
Is this safe to keep in production, or is there a subtlety that makes the guard stricter on purpose?