61 lines
2.8 KiB
Markdown
61 lines
2.8 KiB
Markdown
# 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
|
|
|
|
1. **CREATE:** preserve the cloud UUID `tenants` root and create only Knex-defined tables missing from cloud with `CREATE TABLE IF NOT EXISTS`.
|
|
2. **ALTER:** add follow-up migration columns and inject `tenant_id UUID REFERENCES tenants(id) ON DELETE CASCADE` only where absent.
|
|
3. **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:
|
|
|
|
```sql
|
|
DELETE FROM tenants WHERE id = '5b39bcb5-506a-456d-b7cb-91730b397cc1';
|
|
```
|
|
|
|
## Verification
|
|
|
|
```sql
|
|
SELECT tablename, rowsecurity
|
|
FROM pg_tables
|
|
WHERE schemaname = 'public'
|
|
ORDER BY tablename;
|
|
```
|
|
|
|
Also verify tenant columns and indexes:
|
|
|
|
```sql
|
|
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.
|