2.8 KiB

Raw Blame History

Supabase migration v2

Prerequisites

A backup of the live Supabase database.
SQL Editor access as a role allowed to create extensions, tables, policies, and storage policies.
Supabase schemas/roles (auth, storage, authenticated, anon, service_role) must exist for the RLS/storage sections.
Review supabase_audit_report.md, especially the commented drop candidates.

Strategy

CREATE: preserve the cloud UUID tenants root and create only Knex-defined tables missing from cloud with CREATE TABLE IF NOT EXISTS.
ALTER: add follow-up migration columns and inject tenant_id UUID REFERENCES tenants(id) ON DELETE CASCADE only where absent.
RLS: index every domain tenant_id, enable RLS, and recreate tenant-isolation plus service-role policies idempotently.

Apply

Run supabase_migration_v2.sql once in the Supabase SQL Editor. It is designed for one execution and safe re-execution. The DROP section is entirely commented; do not uncomment it without a backup and code-usage review.

SHOULD-DROP review

assignment_submissions: overlaps submissions; no inbound dump FK, outbound to assignments/users; verify code usage.
attendance_new: canonical table is attendance; no inbound dump FK, outbound to users/subjects_new.
calendar_events: canonical table is events; no inbound dump FK, outbound to users; verify calendar code.
edutainment_content: no inbound dump FK, outbound to subjects_new/users; verify feature retirement.
edutainment_sessions: outbound to edutainment_games/users; drop before or with games.
edutainment_games: inbound from edutainment_sessions; requires sessions-first or CASCADE; outbound to subjects_new/users.
messages_new: canonical table is messages; no inbound dump FK, outbound to users; verify messaging code.

subjects_new must not be dropped: Knex explicitly creates it and multiple dump FKs target it.

Rollback

There is no automatic destructive rollback. Restore the pre-migration backup for a full rollback. For a targeted rollback, drop only newly created tables in reverse dependency order and remove policies/indexes/tenant_id columns only after confirming no tenant data depends on them. The seed can be removed with:

DELETE FROM tenants WHERE id = '5b39bcb5-506a-456d-b7cb-91730b397cc1';

Verification

SELECT tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public'
ORDER BY tablename;

Also verify tenant columns and indexes:

SELECT table_name
FROM information_schema.columns
WHERE table_schema = 'public' AND column_name = 'tenant_id'
ORDER BY table_name;

Tenant UUID alignment

The Knex migration and cloud schema both use UUID tenant IDs. The default test tenant is 5b39bcb5-506a-456d-b7cb-91730b397cc1, and the SuperAdmin controller generates UUIDv4 IDs for new tenants.

2.8 KiB Raw Blame History