Skip to content

fix(migration): quote camelCase identifiers in compression option strings#181

Merged
TerrifiedBug merged 1 commit intomainfrom
fix/timescaledb-compression-camelcase-quoting
Apr 26, 2026
Merged

fix(migration): quote camelCase identifiers in compression option strings#181
TerrifiedBug merged 1 commit intomainfrom
fix/timescaledb-compression-camelcase-quoting

Conversation

@TerrifiedBug
Copy link
Copy Markdown
Owner

Summary

Third in the TimescaleDB-demo bring-up bug series (after #179, #180). Once #180 fixed the missing-column constraint, the migration hit another error on the demo:

```
ERROR: column "pipelineid" does not exist
HINT: The timescaledb.compress_segmentby option must reference a valid column.
```

Note the lowercase `pipelineid` — same bug class as #179. TimescaleDB's parser for `compress_segmentby` and `compress_orderby` folds unquoted identifiers to lowercase. Prisma's columns are camelCase (`pipelineId`, `nodeId`), so `'pipelineId'` was being looked up as `pipelineid` and failing.

Fix

Wrap every column name in double quotes inside the option strings — the same idiom used for the table-name argument in #179.

```sql
ALTER TABLE "PipelineMetric" SET (
timescaledb.compress,
timescaledb.compress_segmentby = '"pipelineId"',
timescaledb.compress_orderby = '"timestamp" DESC, "id"'
);
```

`timestamp` and `id` were already lowercase so they were technically working unquoted, but quoting them too makes the policy here defensive and consistent — a future column rename to e.g. `createdAt` would now still parse correctly without another fix-up.

Why this didn't surface earlier

Same as #179 / #180: every prior deployment ran on plain Postgres, where the `IF EXISTS (... timescaledb)` guard makes this whole migration a no-op. The hosted demo on `timescale/timescaledb:2.16.0-pg16` is the first environment in the wild with the extension installed.

Recovery instructions

For anyone whose DB is currently in the failed state on this migration:

Option A — wipe and reapply (cleanest if no real data, e.g. demo):
```sh
docker compose down -v
docker volume ls | grep vf-demo-pg # verify gone, manual rm if needed
docker compose up
```

Option B — preserve data:
```sh
npx prisma migrate resolve --rolled-back 20260329000001_timescaledb_compression
npx prisma migrate deploy
```

Drift warning for plain-Postgres users

Same caveat as #179 / #180: the migration's checksum changes. On next `prisma migrate deploy` you may see a "migration was modified after applied" warning. Resolve with:

```sh
npx prisma migrate resolve --applied 20260329000001_timescaledb_compression
```

One-time fix; the no-op behaviour on plain Postgres is unchanged.

Test plan

  • Visual inspection — every camelCase column name is now wrapped in escaped quotes
  • Pull this branch into the demo deployment, wipe the volume, restart — both migrations apply cleanly
  • Verify compression policies exist: `SELECT hypertable_name, attname, segmentby_column_index, orderby_column_index FROM timescaledb_information.compression_settings;` — should show `pipelineId`/`nodeId` as a segmentby column and `timestamp` + `id` as orderby columns

…ings

TimescaleDB's parser for compress_segmentby and compress_orderby folds
unquoted identifiers to lowercase (same behaviour as PostgreSQL's
regclass parser, which bit us in #179). Prisma's columns are camelCase
('pipelineId', 'nodeId'), so 'pipelineId' was being looked up as
'pipelineid' and the migration failed with:

  ERROR: column "pipelineid" does not exist
  HINT: The timescaledb.compress_segmentby option must reference a valid column.

Wrap every column name in double quotes inside the option strings —
the same pattern used for the table-name argument in #179.
@github-actions github-actions Bot added the fix label Apr 26, 2026
@TerrifiedBug TerrifiedBug merged commit baeb1ec into main Apr 26, 2026
7 checks passed
@TerrifiedBug TerrifiedBug deleted the fix/timescaledb-compression-camelcase-quoting branch April 26, 2026 18:34
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented Apr 26, 2026

Greptile Summary

This PR fixes a case-sensitivity bug in TimescaleDB compression option strings by wrapping all column identifiers in double quotes inside the option string literals. The fix is applied consistently to all four affected tables (PipelineMetric, NodeMetric, PipelineLog, NodeStatusEvent), matching the established pattern from #179.

Confidence Score: 5/5

Safe to merge — targeted, mechanical fix with no logic changes and consistent application across all four tables.

The fix is a straightforward text correction: adding escaped double-quotes inside four pairs of compression option strings. All four hypertables are updated identically. The add_compression_policy calls are unaffected. The IF EXISTS guard preserves the no-op behaviour on plain Postgres. No logic, schema, or data is altered.

No files require special attention.

Important Files Changed

Filename Overview
prisma/migrations/20260329000001_timescaledb_compression/migration.sql Adds double-quote wrapping around all camelCase column identifiers in compress_segmentby and compress_orderby option strings across all four hypertables; fix is applied consistently and the updated comment accurately describes the two gotchas.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[prisma migrate deploy] --> B{TimescaleDB installed?}
    B -- No --> C[IF EXISTS guard -- no-op on plain Postgres]
    B -- Yes --> D[ALTER TABLE SET compression options with quoted identifiers]
    D --> D1[PipelineMetric -- segmentby pipelineId -- orderby timestamp DESC id]
    D --> D2[NodeMetric -- segmentby nodeId -- orderby timestamp DESC id]
    D --> D3[PipelineLog -- segmentby pipelineId -- orderby timestamp DESC id]
    D --> D4[NodeStatusEvent -- segmentby nodeId -- orderby timestamp DESC id]
    D1 & D2 & D3 & D4 --> E[add_compression_policy 7-day interval per hypertable]
    E --> F[Migration complete]
Loading

Reviews (1): Last reviewed commit: "fix(migration): quote camelCase identifi..." | Re-trigger Greptile

TerrifiedBug added a commit that referenced this pull request Apr 26, 2026
#182)

Bare SELECT inside a PL/pgSQL DO block is invalid when the result is
discarded — Postgres raises 42601 "query has no destination for result
data". Switch the four add_compression_policy calls to PERFORM so the
migration applies cleanly on TimescaleDB.

Follows #179, #180, #181 — same file, same DO block.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant