Skip to content

DRAFT Migrate from record node UUID to internal ID - #119

Open
SteRiccio wants to merge 30 commits into
masterfrom
feat/node-iid
Open

DRAFT Migrate from record node UUID to internal ID#119
SteRiccio wants to merge 30 commits into
masterfrom
feat/node-iid

Conversation

@SteRiccio

Copy link
Copy Markdown
Member

No description provided.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@sonarqubecloud

Copy link
Copy Markdown

@SteRiccio
SteRiccio marked this pull request as draft April 28, 2026 09:14
@SteRiccio SteRiccio changed the title Migrate from record node UUID to internal ID DRAFT Migrate from record node UUID to internal ID Sep 1, 2026
@SteRiccio
SteRiccio marked this pull request as ready for review September 1, 2026 09:43
mergify Bot and others added 4 commits September 1, 2026 09:44
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.
@sonarqubecloud

sonarqubecloud Bot commented Sep 2, 2026

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants