- Shipped
- August 19, 2026 at 7:54 AM UTC
- Author
- Kamo
- Commit
- cbad368
Mirrors the new `User.isFake` field. Four statements, and the order is the whole migration: YugabyteDB rejects `ADD COLUMN … NOT NULL` on a populated table — rejecting the entire statement, not just the offending clause — so the column arrives nullable, is backfilled, gains its DEFAULT, and only then is tightened. Collapsing these into one ALTER produces a migration that logs a warning and leaves the column absent, which is success-shaped output for a total no-op. `@Order(0)` per the column-add convention. The moment the shared-lib entity maps `is_fake`, every later runner that loads a `User` through JPA emits it in its SELECT, so a late-ordered migration would never be reached — an earlier runner dies on `column u1_0.is_fake does not exist` and takes the run down first. The index is partial (`WHERE is_fake = TRUE`). The guard's hot query is "which ids are flagged", and on a table where effectively every row is FALSE a full index on the column is dead weight while a partial one holds a handful of entries. The backfill's `WHERE is_fake IS NULL` is load-bearing, not decoration: KamoInitializer re-runs in full every time, and a bare `UPDATE users SET is_fake = FALSE` would silently un-flag every account an operator had deliberately hidden, on every run. A test asserts that clause is still there. Applied to production 2026-08-19; all five statements logged applied, BUILD SUCCESS. Column verified as `boolean NOT NULL DEFAULT false` with the partial index present.