Debug ClickHouse deserialization errors in Rust caused by column ORDER mismatch when using SELECT alias.* on a VIEW that adds computed columns. Use when: (1) Some query variants (e.g. sort=trending) return 500 but others (sort=recent) succeed, (2) Queries use SELECT view_alias.*, extra_cols FROM view JOIN ..., (3) The Rust Row struct has the right number and types of fields but deserialization fails anyway (wrong type error, not "not enough data"), (4) The VIEW was recently extended with a co...
Scanned 5/27/2026
Install via CLI
openskills install divinevideo/divine-mobile---
name: clickhouse-rust-view-column-order
description: |
Debug ClickHouse deserialization errors in Rust caused by column ORDER mismatch
when using SELECT alias.* on a VIEW that adds computed columns. Use when:
(1) Some query variants (e.g. sort=trending) return 500 but others (sort=recent) succeed,
(2) Queries use SELECT view_alias.*, extra_cols FROM view JOIN ...,
(3) The Rust Row struct has the right number and types of fields but deserialization
fails anyway (wrong type error, not "not enough data"),
(4) The VIEW was recently extended with a computed column (e.g. trending_score).
author: Claude Code
version: 1.0.0
date: 2026-02-25
---
# ClickHouse Rust: View Computed Column Ordering
## Problem
When using `SELECT alias.* , extra_col FROM my_view alias LEFT JOIN ...`, ClickHouse
expands `alias.*` to include ALL columns defined in the view — including any computed
columns added by the view itself (e.g. `SELECT *, expr AS trending_score FROM base`).
Those computed columns appear INSIDE the `alias.*` expansion, BEFORE any columns
appended after it in the outer query.
The `clickhouse` Rust crate (`#[derive(Row)]`) deserializes **positionally** — field N
in the Rust struct receives column N from the query result. If the struct field order
doesn't match the actual SQL column order, the wrong bytes land in the wrong fields,
causing type errors at deserialization even though the column count is correct.
## Symptoms
- HTTP 500 on one sort variant (e.g. `sort=trending`, `sort=popular`) but not others
(e.g. `sort=recent`) that query a different view or table
- Error like: `"cannot decode Float64 from String"` or similar type mismatch
- Column COUNT is correct (no "not enough data" error)
- Bug appears after adding a computed column to an existing view
## Root Cause Explained
Suppose `trending_videos` is defined as:
```sql
CREATE VIEW trending_videos AS
SELECT
*, -- all base columns
(views * 0.5 + likes * 2.0) AS trending_score -- computed column APPENDED HERE
FROM video_stats;
```
An outer query then does:
```sql
SELECT
tv.*, -- expands to: base_cols..., trending_score
text_track_ref, -- subtitle columns come AFTER
text_track_content
FROM trending_videos tv
LEFT JOIN subtitle_subquery USING (id);
```
The actual SQL result column order is:
```
[...base_cols, trending_score, text_track_ref, text_track_content]
```
But if the Rust struct was written with subtitle fields before trending_score:
```rust
pub struct TrendingVideo {
// ...base fields...
pub text_track_ref: String, // position N <- WRONG: gets trending_score bytes
pub text_track_content: String, // position N+1 <- WRONG: gets text_track_ref bytes
pub trending_score: f64, // position N+2 <- WRONG: gets text_track_content bytes
}
```
ClickHouse sends a `Float64` where Rust expects a `String` → deserialization error → 500.
## Why Only Some Queries Fail
The `sort=recent` variant queries `video_stats` directly with `vs.*` — that view has
no extra computed columns, so subtitle columns land at the same relative position the
struct expects. Only the `trending_videos` view adds `trending_score` inside `vs.*`,
shifting everything after it.
## Debugging Steps
1. **Identify which query variants fail vs. succeed.** Failing ones likely use a
different view or have a different `SELECT *` source.
2. **Expand the failing `SELECT alias.*`** — run the inner view query directly:
```bash
curl -u 'user:pass' 'https://clickhouse-host:8443' \
--data-binary "SELECT * FROM trending_videos LIMIT 0 FORMAT TabSeparated"
```
Or use `DESCRIBE TABLE trending_videos` to see declared column order.
3. **List actual column order** of the full outer query:
```bash
curl ... --data-binary \
"SELECT tv.*, '' as text_track_ref, '' as text_track_content
FROM trending_videos tv LIMIT 0 FORMAT TabSeparatedWithNames"
```
4. **Compare with Rust struct field order** line by line — they must match exactly.
5. **Find the misplaced field** — look for computed columns added to the view that
appear inside `alias.*` but after columns that appear in the outer SELECT.
## Fix
Reorder the Rust struct fields to match the actual SQL column order — computed
VIEW columns belong before any columns appended in the outer SELECT:
```rust
pub struct TrendingVideo {
// ...base fields in same order as base table...
// trending_score comes from tv.* (view-computed), so it appears
// BEFORE the subtitle columns we append in the outer query
pub trending_score: f64,
// Subtitle columns are appended after tv.* in the outer SELECT
pub text_track_ref: String,
pub text_track_content: String,
}
```
Do NOT change the SQL query or the view — just align the struct field order.
## Key Rule
> When a ClickHouse VIEW adds a computed column via `SELECT *, expr AS col FROM base`,
> that column becomes part of the view's column list. Any `SELECT alias.*` in an outer
> query will emit it in the view's declared order — BEFORE any extra columns appended
> after `alias.*` in the outer SELECT. The Rust `#[derive(Row)]` struct must reflect
> this exact order.
## Prevention
- When adding a computed column to a ClickHouse view, immediately check ALL Rust
structs that query that view with `SELECT alias.*` and update field ordering.
- Add an integration test that queries the affected endpoint; CI will catch future
ordering drift before staging.
- Consider using `SELECT col1, col2, ..., trending_score, text_track_ref, text_track_content`
(explicit column list instead of `*`) in the outer query to make ordering explicit
and immune to view schema changes.
## Related Skills
- `clickhouse-rust-type-mismatches` — covers "not enough data" (column COUNT mismatch),
FixedString encoding, Option vs String nullability issues. This skill covers column
ORDER mismatch (column count is correct, types match, but positional order is wrong).
## References
- [clickhouse crate Row derive macro](https://docs.rs/clickhouse/latest/clickhouse/derive.Row.html)
- ClickHouse `SELECT *` expansion: follows column declaration order of the source table/view
No comments yet. Be the first to comment!