Ship Pokemon and Lorcana bulk import libs/scripts, unified weekly cron sync across MTG/Pokemon/Lorcana with per-game error isolation and catalog_sync_log telemetry. Admin UI adds Unified/Incremental/Bulk MTG modes. - Rename reconcile migrations to 1781442330* timestamps so they apply after bulk-data migrations without node-pg-migrate ordering conflicts - Add Lorcana set-code normalization + orphan cleanup migrations - Drop stricter user_cards_user_card_unique (keep 3-column foil unique) - Update docs/SCHEMA_MAP.md for tags, card_tags, catalog_sync_log, bulk columns Co-authored-by: Cursor <cursoragent@cursor.com>
98 lines
4.1 KiB
JavaScript
98 lines
4.1 KiB
JavaScript
/**
|
|
* Reconciliation migration — favorites system (B4 of reconcile-historical-add-scripts).
|
|
*
|
|
* Captures the DDL effects of the historical `scripts/add-favorites-system.js`
|
|
* job, which has been applied to every long-lived environment but is NOT
|
|
* reproduced by the post-migration-tool history on a fresh Neon branch. After
|
|
* this migration lands, `npm install` → `npm run setup-db` against a clean
|
|
* branch produces a `user_favorites` table that is structurally equivalent to
|
|
* prod (same columns, same UNIQUE tuple, same four supporting indexes).
|
|
*
|
|
* Source script (READ ONLY, per `.cursor/rules/no-go-zones.mdc`):
|
|
* scripts/add-favorites-system.js
|
|
*
|
|
* Runtime evidence the table exists in prod and that this is the exact shape
|
|
* the API expects:
|
|
* pages/api/favorites.js — SELECT / INSERT / DELETE against
|
|
* `user_favorites` keyed by (user_id, item_type, item_id), with
|
|
* item_type ∈ {'card', 'collection', 'deck'} and a polymorphic item_id.
|
|
*
|
|
* Idempotency (convoy D2):
|
|
* - `CREATE TABLE IF NOT EXISTS` — re-applying against any env where the
|
|
* historical script already ran is a documented no-op.
|
|
* - `CREATE INDEX IF NOT EXISTS` — same idempotency contract for all four
|
|
* indexes.
|
|
* - `UNIQUE(user_id, item_type, item_id)` is declared inline on the table
|
|
* so it is created at the same moment as the table and never needs a
|
|
* separate guarded `ADD CONSTRAINT` path.
|
|
*
|
|
* Shape parity with the historical script:
|
|
* - Same column set (id SERIAL PK, user_id INTEGER FK CASCADE,
|
|
* item_type VARCHAR(50) NOT NULL, item_id INTEGER NOT NULL,
|
|
* created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP).
|
|
* - Same UNIQUE tuple.
|
|
* - Same four index definitions (single-column on user_id, item_type,
|
|
* item_id; composite (user_id, item_type)).
|
|
* - Same index naming (idx_user_favorites_*).
|
|
*
|
|
* FK style follows `migrations/1779853647564_initial-schema.js` —
|
|
* `INTEGER REFERENCES users(id) ON DELETE CASCADE`, no separate FK
|
|
* constraint name.
|
|
*
|
|
* Down-migration is a hard stub: this is a reconciliation migration whose
|
|
* purpose is to bring fresh envs to parity with prod; rolling back would
|
|
* drop `user_favorites` on prod, which is a destructive operation that
|
|
* deserves its own scoped convoy.
|
|
*
|
|
* Note on schema-map terminology drift:
|
|
* `.cursor/rules/schema-map.mdc` § "Common reference" mentions
|
|
* `favorites (user_id, card_id)` — that line is a minimal shorthand and
|
|
* does NOT match the actual prod table (`user_favorites`, polymorphic on
|
|
* item_type + item_id, per `pages/api/favorites.js`). The rule's wording
|
|
* is updated by B7 of this convoy; this migration follows the runtime
|
|
* evidence.
|
|
*
|
|
* @type {import('node-pg-migrate').ColumnDefinitions | undefined}
|
|
*/
|
|
export const shorthands = undefined;
|
|
|
|
/**
|
|
* @param {import('node-pg-migrate').MigrationBuilder} pgm
|
|
* @returns {void}
|
|
*/
|
|
export const up = (pgm) => {
|
|
pgm.sql(`
|
|
CREATE TABLE IF NOT EXISTS user_favorites (
|
|
id SERIAL PRIMARY KEY,
|
|
user_id INTEGER REFERENCES users(id) ON DELETE CASCADE,
|
|
item_type VARCHAR(50) NOT NULL,
|
|
item_id INTEGER NOT NULL,
|
|
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
|
|
UNIQUE(user_id, item_type, item_id)
|
|
)
|
|
`);
|
|
|
|
pgm.sql(`
|
|
CREATE INDEX IF NOT EXISTS idx_user_favorites_user_id
|
|
ON user_favorites(user_id);
|
|
CREATE INDEX IF NOT EXISTS idx_user_favorites_item_type
|
|
ON user_favorites(item_type);
|
|
CREATE INDEX IF NOT EXISTS idx_user_favorites_item_id
|
|
ON user_favorites(item_id);
|
|
CREATE INDEX IF NOT EXISTS idx_user_favorites_user_type
|
|
ON user_favorites(user_id, item_type);
|
|
`);
|
|
};
|
|
|
|
/**
|
|
* @returns {void}
|
|
*/
|
|
export const down = () => {
|
|
throw new Error(
|
|
'[migration:1781000000004_reconcile-favorites-system] Refusing to drop user_favorites. ' +
|
|
'This is a reconciliation migration that brings fresh envs to parity with prod; rolling it ' +
|
|
'back would drop the user_favorites table (and every row in it) on whatever env it runs against. ' +
|
|
'If you need to remove the favorites system, ship a dedicated convoy with a real down() that ' +
|
|
'audits readers (pages/api/favorites.js + any UI surfaces) first.'
|
|
);
|
|
};
|