DRAFT Migrate from record node UUID to internal ID - #119
Conversation
There was a problem hiding this comment.
Pull request overview
This pull request implements a significant database schema change to migrate the node table from using UUID-based identification to internal integer IDs (i_id) scoped within each record. The migration adds new columns i_id and p_i_id to the node table, transforms existing data, updates the activity_log entries to use the new ID scheme, recreates the activity_log_user_aggregate view, and changes the primary key from uuid to a composite key of (record_uuid, i_id).
Changes:
- Add i_id (internal ID) and p_i_id (parent internal ID) columns to the node table
- Migrate meta.h UUID arrays to i_id arrays and update activity_log content structure
- Replace the node table's primary key from uuid to composite (record_uuid, i_id)
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 7 comments.
| File | Description |
|---|---|
| src/db/dbMigrator/migration/survey/migrations/sqls/20260217085512-alter-table-node-add-iid-up.sql | Core migration logic that adds new columns, populates data, updates activity_log, recreates views, and changes primary key |
| src/db/dbMigrator/migration/survey/migrations/sqls/20260217085512-alter-table-node-add-iid-down.sql | Down migration file (currently empty with placeholder) |
| src/db/dbMigrator/migration/survey/migrations/20260217085512-alter-table-node-add-iid.js | JavaScript migration wrapper that loads and executes SQL files |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
The validation-JSON rewrite step in 20260217085512-alter-table-node-add-iid referenced record.id, but the record table's primary key is uuid (it has no id column), so the migration failed with "column r_inner.id does not exist" on every survey schema. Also fills in the previously-empty down migration. Verified against a disposable Postgres container: up migration produces correct i_id/p_i_id, meta.h, and validation.fields rewrites; down migration restores the original schema exactly. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…id down migration The down migration only reverted the schema (columns/constraints), leaving meta.h and record.validation.fields keys in i_id form even after rollback - silently incompatible with pre-migration application code expecting uuids. Mirrors the up migration's transform in reverse, using the still-present uuid column before it's dropped. Verified with a full up -> down -> up round trip against a disposable Postgres instance, including a multi-record scenario where i_id collides across records by design.
…ation to reclaim space i_id/p_i_id now fully supersede uuid/parent_uuid for node identity, so keeping both defeats part of the point of the migration (uuid columns and their indexes are pure overhead once nothing reads them). Drop them once every dependent step - p_i_id population, meta.h rewrite, validation.fields rewrite, and the PK/FK swap - has already read what it needed from them. This makes the migration irreversible: uuid values are random and cannot be reconstructed from i_id/p_i_id once dropped. down() now refuses immediately with a clear error instead of pretending to restore a state it can't actually recover, rather than leaving a partially-reverted, silently-broken schema. Verified with a fresh disposable-Postgres round trip: full up (uuid + parent_uuid dropped, i_id/p_i_id populated, PK/FK on the composite key, meta.h and validation.fields correctly rewritten, a second record's node correctly colliding on i_id=1 to confirm per-record scoping), then confirmed down() rejects without altering the schema.
|



No description provided.