From 6028331016239a41b6c02b1f9689d70a0d80004f Mon Sep 17 00:00:00 2001 From: Claude Date: Tue, 19 May 2026 16:42:03 +0000 Subject: [PATCH 01/18] script: db:recreate:staging end-to-end orchestrator MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Wraps `supabase db reset --linked`, `sync-from-prod.sh staging`, and a TRUNCATE of admin_roles into one command. After it finishes you sign up on the staging UI and call bootstrap_super_admin yourself — the script can't sign you up. sync-from-prod.sh now honors SKIP_CONFIRM=1 so the wrapper can call it non-interactively after the wrapper's own confirmation. --- package.json | 1 + scripts/recreate-staging.sh | 85 +++++++++++++++++++++++++++++++++++++ scripts/sync-from-prod.sh | 10 +++-- 3 files changed, 92 insertions(+), 4 deletions(-) create mode 100755 scripts/recreate-staging.sh diff --git a/package.json b/package.json index 9b1d1c73..564af51c 100644 --- a/package.json +++ b/package.json @@ -28,6 +28,7 @@ "types:generate:local": "supabase gen types typescript --local > src/integrations/supabase/types.ts", "db:sync:staging": "bash scripts/sync-from-prod.sh staging", "db:sync:local": "bash scripts/sync-from-prod.sh local", + "db:recreate:staging": "bash scripts/recreate-staging.sh", "typecheck": "tsc --noEmit --project tsconfig.app.json", "prepare": "husky" }, diff --git a/scripts/recreate-staging.sh b/scripts/recreate-staging.sh new file mode 100755 index 00000000..7cfa1aad --- /dev/null +++ b/scripts/recreate-staging.sh @@ -0,0 +1,85 @@ +#!/usr/bin/env bash +# +# Recreate staging from scratch: reset schema, re-run every migration from +# the current branch, sync anonymized prod data, and clear admin_roles so +# you can bootstrap yourself. +# +# Usage: +# pnpm run db:recreate:staging +# +# After it finishes: +# 1. Sign up on the staging UI with the email you want to be admin. +# 2. In the Supabase dashboard SQL editor (or psql against $STAGING_DB_URL): +# SELECT public.bootstrap_super_admin('you@example.com'); +# +# Required env vars (put them in scripts/.env.sync, which is gitignored): +# STAGING_PROJECT_REF Supabase project ref for staging +# STAGING_DB_PASSWORD Staging DB password (for `supabase link`) +# STAGING_DB_URL Direct postgres URL for staging +# PROD_DB_URL Direct postgres URL for prod +# +set -euo pipefail + +SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" +ENV_FILE="$SCRIPT_DIR/.env.sync" +if [[ -f "$ENV_FILE" ]]; then + set -a + # shellcheck disable=SC1090 + source "$ENV_FILE" + set +a +fi + +: "${STAGING_PROJECT_REF:?STAGING_PROJECT_REF is required}" +: "${STAGING_DB_PASSWORD:?STAGING_DB_PASSWORD is required}" +: "${STAGING_DB_URL:?STAGING_DB_URL is required}" +: "${PROD_DB_URL:?PROD_DB_URL is required}" + +if [[ "$STAGING_DB_URL" == "$PROD_DB_URL" ]]; then + echo "Refusing: STAGING_DB_URL equals PROD_DB_URL." >&2 + exit 1 +fi + +BRANCH="$(git rev-parse --abbrev-ref HEAD)" + +cat < Date: Wed, 20 May 2026 05:42:38 +0000 Subject: [PATCH 02/18] script: recreate-staging creates and promotes the admin user MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The script now takes an admin email argument and fully provisions the account: it creates the auth user via the admin Auth API (email_confirm true) and runs bootstrap_super_admin. Password comes from ADMIN_PASSWORD or is generated and printed. Re-runs are safe — an already-registered email is kept rather than treated as an error. Needs STAGING_URL and STAGING_SERVICE_ROLE_KEY in scripts/.env.sync. --- scripts/recreate-staging.sh | 98 +++++++++++++++++++++++++++++-------- 1 file changed, 77 insertions(+), 21 deletions(-) diff --git a/scripts/recreate-staging.sh b/scripts/recreate-staging.sh index 7cfa1aad..f7a3c18d 100755 --- a/scripts/recreate-staging.sh +++ b/scripts/recreate-staging.sh @@ -1,25 +1,31 @@ #!/usr/bin/env bash # # Recreate staging from scratch: reset schema, re-run every migration from -# the current branch, sync anonymized prod data, and clear admin_roles so -# you can bootstrap yourself. +# the current branch, sync anonymized prod data, create your admin user, and +# promote it to super_admin. # # Usage: -# pnpm run db:recreate:staging +# pnpm run db:recreate:staging you@example.com # -# After it finishes: -# 1. Sign up on the staging UI with the email you want to be admin. -# 2. In the Supabase dashboard SQL editor (or psql against $STAGING_DB_URL): -# SELECT public.bootstrap_super_admin('you@example.com'); +# Password: set ADMIN_PASSWORD to choose your own, otherwise one is generated +# and printed at the end. # # Required env vars (put them in scripts/.env.sync, which is gitignored): -# STAGING_PROJECT_REF Supabase project ref for staging -# STAGING_DB_PASSWORD Staging DB password (for `supabase link`) -# STAGING_DB_URL Direct postgres URL for staging -# PROD_DB_URL Direct postgres URL for prod +# STAGING_PROJECT_REF Supabase project ref for staging +# STAGING_DB_PASSWORD Staging DB password (for `supabase link`) +# STAGING_DB_URL Direct postgres URL for staging +# PROD_DB_URL Direct postgres URL for prod +# STAGING_URL Staging project URL (https://.supabase.co) +# STAGING_SERVICE_ROLE_KEY Staging service role key (for the admin Auth API) # set -euo pipefail +ADMIN_EMAIL="${1:-}" +if [[ -z "$ADMIN_EMAIL" ]]; then + echo "Usage: $0 " >&2 + exit 1 +fi + SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" ENV_FILE="$SCRIPT_DIR/.env.sync" if [[ -f "$ENV_FILE" ]]; then @@ -33,12 +39,21 @@ fi : "${STAGING_DB_PASSWORD:?STAGING_DB_PASSWORD is required}" : "${STAGING_DB_URL:?STAGING_DB_URL is required}" : "${PROD_DB_URL:?PROD_DB_URL is required}" +: "${STAGING_URL:?STAGING_URL is required}" +: "${STAGING_SERVICE_ROLE_KEY:?STAGING_SERVICE_ROLE_KEY is required}" if [[ "$STAGING_DB_URL" == "$PROD_DB_URL" ]]; then echo "Refusing: STAGING_DB_URL equals PROD_DB_URL." >&2 exit 1 fi +ADMIN_PASSWORD="${ADMIN_PASSWORD:-}" +GENERATED_PASSWORD=0 +if [[ -z "$ADMIN_PASSWORD" ]]; then + ADMIN_PASSWORD="$(openssl rand -base64 18)" + GENERATED_PASSWORD=1 +fi + BRANCH="$(git rev-parse --abbrev-ref HEAD)" cat <&2 + echo "$CREATE_RESPONSE" >&2 + exit 1 + fi +fi + +echo "→ Promoting '$ADMIN_EMAIL' to super_admin…" +psql "$STAGING_DB_URL" -v ON_ERROR_STOP=1 \ + -c "SELECT public.bootstrap_super_admin('$ADMIN_EMAIL');" + cat < Date: Wed, 20 May 2026 05:48:04 +0000 Subject: [PATCH 03/18] docs: add db:recreate:staging vars to .env.sync.example Lists STAGING_PROJECT_REF, STAGING_DB_PASSWORD, STAGING_URL, and STAGING_SERVICE_ROLE_KEY, which the recreate-staging script needs but the example file never documented. --- scripts/.env.sync.example | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/scripts/.env.sync.example b/scripts/.env.sync.example index fc67e511..5774e0e7 100644 --- a/scripts/.env.sync.example +++ b/scripts/.env.sync.example @@ -1,7 +1,7 @@ # Copy this file to scripts/.env.sync and fill in values. # scripts/.env.sync is gitignored — never commit real connection strings. # -# Find these in Supabase Dashboard -> Project Settings -> Database +# DB URLs: Supabase Dashboard -> Project Settings -> Database # -> Connection string -> URI (use the "Direct connection" string, not the pooler). PROD_DB_URL="postgresql://postgres:PASSWORD@db.qssmazlqrmxiudxckxvi.supabase.co:5432/postgres" @@ -9,3 +9,15 @@ STAGING_DB_URL="postgresql://postgres:PASSWORD@db.YOUR-STAGING-REF.supabase.co:5 # Optional — defaults to the Supabase CLI's local DB. # LOCAL_DB_URL="postgresql://postgres:postgres@127.0.0.1:54322/postgres" + +# --- Required only for `pnpm run db:recreate:staging` --- +# +# STAGING_PROJECT_REF / STAGING_DB_PASSWORD: used for `supabase link`. +# Ref is in the dashboard URL; password is the DB password. +STAGING_PROJECT_REF="YOUR-STAGING-REF" +STAGING_DB_PASSWORD="YOUR-STAGING-DB-PASSWORD" + +# STAGING_URL / STAGING_SERVICE_ROLE_KEY: used to create the admin auth user. +# URL is the project URL; service role key is in Project Settings -> API. +STAGING_URL="https://YOUR-STAGING-REF.supabase.co" +STAGING_SERVICE_ROLE_KEY="YOUR-STAGING-SERVICE-ROLE-KEY" From b85820d079f354dee896ff1d842d074fcc5305f2 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 20 May 2026 06:47:20 +0000 Subject: [PATCH 04/18] docs: use session pooler connection string in .env.sync.example The direct connection host (db..supabase.co) is IPv6-only and fails with "could not translate host name" on IPv4 networks. The session pooler host is IPv4-compatible and works with pg_dump/psql. https://claude.ai/code/session_01T7UYCNxqTRMB4HJ6pk1nEm --- scripts/.env.sync.example | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/scripts/.env.sync.example b/scripts/.env.sync.example index 5774e0e7..3dadf89d 100644 --- a/scripts/.env.sync.example +++ b/scripts/.env.sync.example @@ -1,11 +1,17 @@ # Copy this file to scripts/.env.sync and fill in values. # scripts/.env.sync is gitignored — never commit real connection strings. # -# DB URLs: Supabase Dashboard -> Project Settings -> Database -# -> Connection string -> URI (use the "Direct connection" string, not the pooler). +# DB URLs: Supabase Dashboard -> Connect -> Connection string. +# Use the "Session pooler" string (port 5432) — it is IPv4-compatible and +# works with pg_dump/psql. The "Direct connection" host (db..supabase.co) +# is IPv6-only and fails with "could not translate host name" on IPv4 networks. +# Do NOT use the "Transaction pooler" (port 6543) — pg_dump needs session mode. +# +# Session pooler format: +# postgresql://postgres.:PASSWORD@aws-0-.pooler.supabase.com:5432/postgres -PROD_DB_URL="postgresql://postgres:PASSWORD@db.qssmazlqrmxiudxckxvi.supabase.co:5432/postgres" -STAGING_DB_URL="postgresql://postgres:PASSWORD@db.YOUR-STAGING-REF.supabase.co:5432/postgres" +PROD_DB_URL="postgresql://postgres.qssmazlqrmxiudxckxvi:PASSWORD@aws-0-YOUR-REGION.pooler.supabase.com:5432/postgres" +STAGING_DB_URL="postgresql://postgres.YOUR-STAGING-REF:PASSWORD@aws-0-YOUR-REGION.pooler.supabase.com:5432/postgres" # Optional — defaults to the Supabase CLI's local DB. # LOCAL_DB_URL="postgresql://postgres:postgres@127.0.0.1:54322/postgres" From a20b72adc473c1dd2946da9898ee9fbecb4ba38c Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 20 May 2026 06:51:57 +0000 Subject: [PATCH 05/18] fix: handle duplicate artist slugs when syncing prod data Prod data can pre-date the slug-dedupe migration, so restoring it into a target that already has the artists_slug_unique constraint fails. Drop the constraint before restore, then dedupe and re-add it afterwards. https://claude.ai/code/session_01T7UYCNxqTRMB4HJ6pk1nEm --- scripts/sync-from-prod.sh | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/scripts/sync-from-prod.sh b/scripts/sync-from-prod.sh index f4a6b15f..b27c5036 100755 --- a/scripts/sync-from-prod.sh +++ b/scripts/sync-from-prod.sh @@ -146,6 +146,13 @@ BEGIN END $$; SQL +echo "Relaxing artists.slug uniqueness for restore…" +# Prod may pre-date the slug-dedupe migration, so its data can contain +# duplicate slugs that would violate the target's constraint. Drop it now +# and re-add it (with a dedupe pass) after the restore. +psql "$TARGET_URL" -v ON_ERROR_STOP=1 \ + -c "ALTER TABLE public.artists DROP CONSTRAINT IF EXISTS artists_slug_unique;" + echo "Restoring dump into target…" psql "$TARGET_URL" -v ON_ERROR_STOP=1 < 1 +); +ALTER TABLE public.artists ADD CONSTRAINT artists_slug_unique UNIQUE (slug); +SQL + echo "Running anonymizer on public schema…" psql "$TARGET_URL" -v ON_ERROR_STOP=1 -f "$SCRIPT_DIR/anonymize.sql" From 3289d49ac319abbe4f9d7024bc67ee46ffe1b17c Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 20 May 2026 06:59:41 +0000 Subject: [PATCH 06/18] chore: neutralize legacy artist seed migration Seed data does not belong in migrations -- supabase/seed.sql is the supported mechanism. The hardcoded roster and system@boom-voter.local auth user (which also needed pgcrypto's gen_salt) are removed; the file is kept as a no-op so migration history stays intact where it already ran. https://claude.ai/code/session_01T7UYCNxqTRMB4HJ6pk1nEm --- .../20250620080928_seed_artists_data.sql | 81 ++----------------- 1 file changed, 8 insertions(+), 73 deletions(-) diff --git a/supabase/migrations/20250620080928_seed_artists_data.sql b/supabase/migrations/20250620080928_seed_artists_data.sql index 16f821fa..f59629e1 100644 --- a/supabase/migrations/20250620080928_seed_artists_data.sql +++ b/supabase/migrations/20250620080928_seed_artists_data.sql @@ -1,73 +1,8 @@ - --- First, add the missing "Tribal/bass" genre (only if it doesn't exist) -INSERT INTO public.music_genres (name, created_by) -SELECT 'Tribal/bass', NULL -WHERE NOT EXISTS (SELECT 1 FROM public.music_genres WHERE name = 'Tribal/bass'); - --- Create a system user in auth.users if no profiles exist -INSERT INTO auth.users (id, email, encrypted_password, email_confirmed_at, created_at, updated_at, raw_user_meta_data, is_super_admin, confirmation_token, recovery_token) -SELECT - '00000000-0000-0000-0000-000000000000'::uuid, - 'system@boom-voter.local', - crypt('system-password', gen_salt('bf')), - now(), - now(), - now(), - '{"username": "system"}'::jsonb, - false, - '', - '' -WHERE NOT EXISTS (SELECT 1 FROM public.profiles LIMIT 1); - --- Create the corresponding profile for the system user -INSERT INTO public.profiles (id, username) -SELECT - '00000000-0000-0000-0000-000000000000'::uuid, - 'system' -WHERE NOT EXISTS (SELECT 1 FROM public.profiles LIMIT 1); - --- Now insert all the artists with proper genre mapping using the system user -INSERT INTO public.artists (name, description, genre_id, added_by) VALUES --- Artists with Downtempo genre -('Merkaba', '', (SELECT id FROM public.music_genres WHERE name = 'Downtempo'), '00000000-0000-0000-0000-000000000000'::uuid), -('Twofold', 'Up Downtempo. Maybe house? I have no idea', (SELECT id FROM public.music_genres WHERE name = 'Downtempo'), '00000000-0000-0000-0000-000000000000'::uuid), -('Imanu', 'D&B', (SELECT id FROM public.music_genres WHERE name = 'Downtempo'), '00000000-0000-0000-0000-000000000000'::uuid), -('Bayawaka', '', (SELECT id FROM public.music_genres WHERE name = 'Downtempo'), '00000000-0000-0000-0000-000000000000'::uuid), -('SensoRythm', '', (SELECT id FROM public.music_genres WHERE name = 'Downtempo'), '00000000-0000-0000-0000-000000000000'::uuid), -('Goopsteppa', '', (SELECT id FROM public.music_genres WHERE name = 'Downtempo'), '00000000-0000-0000-0000-000000000000'::uuid), -('Drrtywulvz', '', (SELECT id FROM public.music_genres WHERE name = 'Downtempo'), '00000000-0000-0000-0000-000000000000'::uuid), -('Kalya Scintilla', '', (SELECT id FROM public.music_genres WHERE name = 'Downtempo'), '00000000-0000-0000-0000-000000000000'::uuid), - --- Artists with Techno genre -('Carbon', '', (SELECT id FROM public.music_genres WHERE name = 'Techno'), '00000000-0000-0000-0000-000000000000'::uuid), -('Frida Darko', '', (SELECT id FROM public.music_genres WHERE name = 'Techno'), '00000000-0000-0000-0000-000000000000'::uuid), -('Richie Hawtin', '', (SELECT id FROM public.music_genres WHERE name = 'Techno'), '00000000-0000-0000-0000-000000000000'::uuid), - --- Artists with Trance genre -('Digicult', 'Can be aggressive', (SELECT id FROM public.music_genres WHERE name = 'Trance'), '00000000-0000-0000-0000-000000000000'::uuid), -('Ace Ventura', '', (SELECT id FROM public.music_genres WHERE name = 'Trance'), '00000000-0000-0000-0000-000000000000'::uuid), -('Astrix', '', (SELECT id FROM public.music_genres WHERE name = 'Trance'), '00000000-0000-0000-0000-000000000000'::uuid), -('Atmos', '', (SELECT id FROM public.music_genres WHERE name = 'Trance'), '00000000-0000-0000-0000-000000000000'::uuid), -('Tristan', '', (SELECT id FROM public.music_genres WHERE name = 'Trance'), '00000000-0000-0000-0000-000000000000'::uuid), -('Tsuyoshi Suzuki', '', (SELECT id FROM public.music_genres WHERE name = 'Trance'), '00000000-0000-0000-0000-000000000000'::uuid), -('John Fleming', 'I think a bit pop but fun', (SELECT id FROM public.music_genres WHERE name = 'Trance'), '00000000-0000-0000-0000-000000000000'::uuid), -('Akari System', '', (SELECT id FROM public.music_genres WHERE name = 'Trance'), '00000000-0000-0000-0000-000000000000'::uuid), -('Miles from Mars', '', (SELECT id FROM public.music_genres WHERE name = 'Trance'), '00000000-0000-0000-0000-000000000000'::uuid), -('Neurolabz', '', (SELECT id FROM public.music_genres WHERE name = 'Trance'), '00000000-0000-0000-0000-000000000000'::uuid), - --- Artists with Tribal/bass genre -('Tor', '', (SELECT id FROM public.music_genres WHERE name = 'Tribal/bass'), '00000000-0000-0000-0000-000000000000'::uuid), -('Liquid Bloom', 'Can be chillout', (SELECT id FROM public.music_genres WHERE name = 'Tribal/bass'), '00000000-0000-0000-0000-000000000000'::uuid), -('Nyrus', '', (SELECT id FROM public.music_genres WHERE name = 'Tribal/bass'), '00000000-0000-0000-0000-000000000000'::uuid), - --- Artists with Psytrance genre (researched missing genres) -('Kliment', '', (SELECT id FROM public.music_genres WHERE name = 'Psytrance'), '00000000-0000-0000-0000-000000000000'::uuid), -('Prometheus', '', (SELECT id FROM public.music_genres WHERE name = 'Psytrance'), '00000000-0000-0000-0000-000000000000'::uuid), -('Atia', '', (SELECT id FROM public.music_genres WHERE name = 'Psytrance'), '00000000-0000-0000-0000-000000000000'::uuid), -('Dnox and Becker', '', (SELECT id FROM public.music_genres WHERE name = 'Psytrance'), '00000000-0000-0000-0000-000000000000'::uuid), -('Freedom Fighters', '', (SELECT id FROM public.music_genres WHERE name = 'Psytrance'), '00000000-0000-0000-0000-000000000000'::uuid), -('Krumelur', '', (SELECT id FROM public.music_genres WHERE name = 'Psytrance'), '00000000-0000-0000-0000-000000000000'::uuid), -('Ritmo', '', (SELECT id FROM public.music_genres WHERE name = 'Psytrance'), '00000000-0000-0000-0000-000000000000'::uuid), - --- Artists with Progressive genre -('Boundless', '', (SELECT id FROM public.music_genres WHERE name = 'Progressive'), '00000000-0000-0000-0000-000000000000'::uuid); +-- Neutralized: this migration originally seeded a hardcoded artist roster and +-- a `system@boom-voter.local` auth user. Seed data does not belong in +-- migrations -- supabase/seed.sql is the supported mechanism and the CLI +-- applies it automatically on `db reset` / `start`. Staging/prod-like data +-- comes from scripts/sync-from-prod.sh. +-- +-- The body is kept as a no-op so the migration history stays intact on +-- environments where it already ran. From d93547f9153c4a25adf9da3c60a2997436fb342a Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 16 May 2026 17:33:03 +0000 Subject: [PATCH 07/18] fix(types): strip derived join fields before insert/update soundcloud_followers and stage_name live on our enriched row types but aren't real columns. Supabase-js now flags them via RejectExcessProperties on .insert/.update, so destructure them out of the payload. --- src/hooks/queries/artists/useUpdateArtist.ts | 2 +- src/hooks/queries/sets/useCreateSet.ts | 4 +++- src/hooks/queries/sets/useUpdateSet.ts | 3 ++- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/src/hooks/queries/artists/useUpdateArtist.ts b/src/hooks/queries/artists/useUpdateArtist.ts index 720a7403..7dd4b6cb 100644 --- a/src/hooks/queries/artists/useUpdateArtist.ts +++ b/src/hooks/queries/artists/useUpdateArtist.ts @@ -14,7 +14,7 @@ async function updateArtist(variables: { updates: UpdateArtistUpdates; }): Promise> { const { id, updates } = variables; - const { genre_ids, ...rest } = updates; + const { genre_ids, soundcloud_followers: _sf, ...rest } = updates; // If name is being updated, regenerate slug const updateData = { ...rest }; diff --git a/src/hooks/queries/sets/useCreateSet.ts b/src/hooks/queries/sets/useCreateSet.ts index 7c4bd615..e4f8004c 100644 --- a/src/hooks/queries/sets/useCreateSet.ts +++ b/src/hooks/queries/sets/useCreateSet.ts @@ -18,11 +18,13 @@ async function createSet( | "slug" >, ): Promise { + const { stage_name: _sn, ...rest } = setData; + // First, create the set without slug const { data, error } = await supabase .from("sets") .insert({ - ...setData, + ...rest, slug: generateSlug(setData.name), archived: false, // Explicit default }) diff --git a/src/hooks/queries/sets/useUpdateSet.ts b/src/hooks/queries/sets/useUpdateSet.ts index 6e3f2a3a..2d39e071 100644 --- a/src/hooks/queries/sets/useUpdateSet.ts +++ b/src/hooks/queries/sets/useUpdateSet.ts @@ -10,9 +10,10 @@ async function updateSet(variables: { updates: Partial>; }) { const { id, updates } = variables; + const { stage_name: _sn, ...rest } = updates; // If name is being updated, regenerate slug - const updateData = { ...updates }; + const updateData = { ...rest }; if (updates.name) { updateData.slug = generateSlug(updates.name); } From 7a8d08d68f5248cf4bfcee12fe3bad596d04f43c Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 20 May 2026 07:02:01 +0000 Subject: [PATCH 08/18] fix: raise PWA precache file-size limit to 3 MiB The main JS bundle exceeds the workbox 2 MiB default, which fails the Vercel build. Bump maximumFileSizeToCacheInBytes so the bundle is precached. https://claude.ai/code/session_01T7UYCNxqTRMB4HJ6pk1nEm --- vite.config.ts | 1 + 1 file changed, 1 insertion(+) diff --git a/vite.config.ts b/vite.config.ts index 74be376c..cf727f98 100644 --- a/vite.config.ts +++ b/vite.config.ts @@ -23,6 +23,7 @@ export default defineConfig(({ mode }) => ({ workbox: { globPatterns: ["**/*.{js,css,html,ico,png,svg,webp,woff,woff2}"], navigateFallback: "/index.html", + maximumFileSizeToCacheInBytes: 3 * 1024 * 1024, }, includeAssets: [ "favicon.svg", From 5d35daee701799c70f4bcf0a8d189d5ebf8d6639 Mon Sep 17 00:00:00 2001 From: Chaim Lev-Ari Date: Wed, 20 May 2026 10:00:07 +0300 Subject: [PATCH 09/18] fix(db/mig): only create assets bucket if not exist --- supabase/migrations/20250811140000_add_festival_logo.sql | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/supabase/migrations/20250811140000_add_festival_logo.sql b/supabase/migrations/20250811140000_add_festival_logo.sql index ee3a53f2..4d002e00 100644 --- a/supabase/migrations/20250811140000_add_festival_logo.sql +++ b/supabase/migrations/20250811140000_add_festival_logo.sql @@ -7,7 +7,8 @@ COMMENT ON COLUMN public.festivals.logo_url IS 'URL to the festival logo image s -- Create the festival-assets storage bucket for storing festival logos INSERT INTO storage.buckets (id, name, public) -VALUES ('festival-assets', 'festival-assets', true); +VALUES ('festival-assets', 'festival-assets', true) +ON CONFLICT (id) DO NOTHING; -- Set up RLS policy for the storage bucket -- Allow public read access to all files in the festival-assets bucket From 54afeb20569cfcedeb45ff5cd7ee0e61356b5de9 Mon Sep 17 00:00:00 2001 From: Chaim Lev-Ari Date: Wed, 20 May 2026 10:01:02 +0300 Subject: [PATCH 10/18] feat(claude): add supabase skills --- .../supabase-postgres-best-practices/SKILL.md | 66 +++++++ .../references/_contributing.md | 170 ++++++++++++++++++ .../references/_sections.md | 47 +++++ .../references/_template.md | 34 ++++ .../references/advanced-full-text-search.md | 55 ++++++ .../references/advanced-jsonb-indexing.md | 49 +++++ .../references/conn-idle-timeout.md | 46 +++++ .../references/conn-limits.md | 44 +++++ .../references/conn-pooling.md | 41 +++++ .../references/conn-prepared-statements.md | 46 +++++ .../references/data-batch-inserts.md | 54 ++++++ .../references/data-n-plus-one.md | 53 ++++++ .../references/data-pagination.md | 50 ++++++ .../references/data-upsert.md | 50 ++++++ .../references/lock-advisory.md | 56 ++++++ .../references/lock-deadlock-prevention.md | 68 +++++++ .../references/lock-short-transactions.md | 50 ++++++ .../references/lock-skip-locked.md | 54 ++++++ .../references/monitor-explain-analyze.md | 45 +++++ .../references/monitor-pg-stat-statements.md | 55 ++++++ .../references/monitor-vacuum-analyze.md | 55 ++++++ .../references/query-composite-indexes.md | 44 +++++ .../references/query-covering-indexes.md | 40 +++++ .../references/query-index-types.md | 48 +++++ .../references/query-missing-indexes.md | 43 +++++ .../references/query-partial-indexes.md | 45 +++++ .../references/schema-constraints.md | 80 +++++++++ .../references/schema-data-types.md | 46 +++++ .../references/schema-foreign-key-indexes.md | 59 ++++++ .../schema-lowercase-identifiers.md | 55 ++++++ .../references/schema-partitioning.md | 55 ++++++ .../references/schema-primary-keys.md | 61 +++++++ .../references/security-privileges.md | 54 ++++++ .../references/security-rls-basics.md | 50 ++++++ .../references/security-rls-performance.md | 63 +++++++ .agents/skills/supabase/SKILL.md | 132 ++++++++++++++ .../assets/feedback-issue-template.md | 17 ++ .../supabase/references/skill-feedback.md | 17 ++ .claude/skills/supabase | 1 + .../skills/supabase-postgres-best-practices | 1 + skills-lock.json | 17 ++ 41 files changed, 2116 insertions(+) create mode 100644 .agents/skills/supabase-postgres-best-practices/SKILL.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/_contributing.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/_sections.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/_template.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/advanced-full-text-search.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/advanced-jsonb-indexing.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/conn-idle-timeout.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/conn-limits.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/conn-pooling.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/conn-prepared-statements.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/data-batch-inserts.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/data-n-plus-one.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/data-pagination.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/data-upsert.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/lock-advisory.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/lock-deadlock-prevention.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/lock-short-transactions.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/lock-skip-locked.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/monitor-explain-analyze.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/monitor-pg-stat-statements.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/monitor-vacuum-analyze.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/query-composite-indexes.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/query-covering-indexes.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/query-index-types.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/query-missing-indexes.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/query-partial-indexes.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/schema-constraints.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/schema-data-types.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/schema-foreign-key-indexes.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/schema-lowercase-identifiers.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/schema-partitioning.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/schema-primary-keys.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/security-privileges.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/security-rls-basics.md create mode 100644 .agents/skills/supabase-postgres-best-practices/references/security-rls-performance.md create mode 100644 .agents/skills/supabase/SKILL.md create mode 100644 .agents/skills/supabase/assets/feedback-issue-template.md create mode 100644 .agents/skills/supabase/references/skill-feedback.md create mode 120000 .claude/skills/supabase create mode 120000 .claude/skills/supabase-postgres-best-practices create mode 100644 skills-lock.json diff --git a/.agents/skills/supabase-postgres-best-practices/SKILL.md b/.agents/skills/supabase-postgres-best-practices/SKILL.md new file mode 100644 index 00000000..07aa1b3a --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/SKILL.md @@ -0,0 +1,66 @@ +--- +name: supabase-postgres-best-practices +description: Postgres performance optimization and best practices from Supabase. Use this skill when writing, reviewing, or optimizing Postgres queries, schema designs, or database configurations. +license: MIT +metadata: + author: supabase + version: "1.1.1" + organization: Supabase + date: January 2026 + abstract: Comprehensive Postgres performance optimization guide for developers using Supabase and Postgres. Contains performance rules across 8 categories, prioritized by impact from critical (query performance, connection management) to incremental (advanced features). Each rule includes detailed explanations, incorrect vs. correct SQL examples, query plan analysis, and specific performance metrics to guide automated optimization and code generation. +--- + +# Supabase Postgres Best Practices + +Comprehensive performance optimization guide for Postgres, maintained by Supabase. Contains rules across 8 categories, prioritized by impact to guide automated query optimization and schema design. + +## When to Apply + +Reference these guidelines when: + +- Writing SQL queries or designing schemas +- Implementing indexes or query optimization +- Reviewing database performance issues +- Configuring connection pooling or scaling +- Optimizing for Postgres-specific features +- Working with Row-Level Security (RLS) + +## Rule Categories by Priority + +| Priority | Category | Impact | Prefix | +| -------- | ------------------------ | ----------- | ----------- | +| 1 | Query Performance | CRITICAL | `query-` | +| 2 | Connection Management | CRITICAL | `conn-` | +| 3 | Security & RLS | CRITICAL | `security-` | +| 4 | Schema Design | HIGH | `schema-` | +| 5 | Concurrency & Locking | MEDIUM-HIGH | `lock-` | +| 6 | Data Access Patterns | MEDIUM | `data-` | +| 7 | Monitoring & Diagnostics | LOW-MEDIUM | `monitor-` | +| 8 | Advanced Features | LOW | `advanced-` | + +## How to Use + +Read individual rule files for detailed explanations and SQL examples: + +``` +references/query-missing-indexes.md +references/query-partial-indexes.md +references/_sections.md +``` + +Each rule file contains: + +- Brief explanation of why it matters +- Incorrect SQL example with explanation +- Correct SQL example with explanation +- Optional EXPLAIN output or metrics +- Additional context and references +- Supabase-specific notes (when applicable) + +## References + +- https://www.postgresql.org/docs/current/ +- https://supabase.com/docs +- https://wiki.postgresql.org/wiki/Performance_Optimization +- https://supabase.com/docs/guides/database/overview +- https://supabase.com/docs/guides/auth/row-level-security diff --git a/.agents/skills/supabase-postgres-best-practices/references/_contributing.md b/.agents/skills/supabase-postgres-best-practices/references/_contributing.md new file mode 100644 index 00000000..54962471 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/_contributing.md @@ -0,0 +1,170 @@ +# Writing Guidelines for Postgres References + +This document provides guidelines for creating effective Postgres best +practice references that work well with AI agents and LLMs. + +## Key Principles + +### 1. Concrete Transformation Patterns + +Show exact SQL rewrites. Avoid philosophical advice. + +**Good:** "Use `WHERE id = ANY(ARRAY[...])` instead of +`WHERE id IN (SELECT ...)`" **Bad:** "Design good schemas" + +### 2. Error-First Structure + +Always show the problematic pattern first, then the solution. This trains agents +to recognize anti-patterns. + +```markdown +**Incorrect (sequential queries):** [bad example] + +**Correct (batched query):** [good example] +``` + +### 3. Quantified Impact + +Include specific metrics. Helps agents prioritize fixes. + +**Good:** "10x faster queries", "50% smaller index", "Eliminates N+1" +**Bad:** "Faster", "Better", "More efficient" + +### 4. Self-Contained Examples + +Examples should be complete and runnable (or close to it). Include `CREATE TABLE` +if context is needed. + +```sql +-- Include table definition when needed for clarity +CREATE TABLE users ( + id bigint PRIMARY KEY, + email text NOT NULL, + deleted_at timestamptz +); + +-- Now show the index +CREATE INDEX users_active_email_idx ON users(email) WHERE deleted_at IS NULL; +``` + +### 5. Semantic Naming + +Use meaningful table/column names. Names carry intent for LLMs. + +**Good:** `users`, `email`, `created_at`, `is_active` +**Bad:** `table1`, `col1`, `field`, `flag` + +--- + +## Code Example Standards + +### SQL Formatting + +```sql +-- Use lowercase keywords, clear formatting +CREATE INDEX CONCURRENTLY users_email_idx + ON users(email) + WHERE deleted_at IS NULL; + +-- Not cramped or ALL CAPS +CREATE INDEX CONCURRENTLY USERS_EMAIL_IDX ON USERS(EMAIL) WHERE DELETED_AT IS NULL; +``` + +### Comments + +- Explain _why_, not _what_ +- Highlight performance implications +- Point out common pitfalls + +### Language Tags + +- `sql` - Standard SQL queries +- `plpgsql` - Stored procedures/functions +- `typescript` - Application code (when needed) +- `python` - Application code (when needed) + +--- + +## When to Include Application Code + +**Default: SQL Only** + +Most references should focus on pure SQL patterns. This keeps examples portable. + +**Include Application Code When:** + +- Connection pooling configuration +- Transaction management in application context +- ORM anti-patterns (N+1 in Prisma/TypeORM) +- Prepared statement usage + +**Format for Mixed Examples:** + +````markdown +**Incorrect (N+1 in application):** + +```typescript +for (const user of users) { + const posts = await db.query("SELECT * FROM posts WHERE user_id = $1", [ + user.id, + ]); +} +``` +```` + +**Correct (batch query):** + +```typescript +const posts = await db.query("SELECT * FROM posts WHERE user_id = ANY($1)", [ + userIds, +]); +``` + +--- + +## Impact Level Guidelines + +| Level | Improvement | Use When | +| --------------- | ----------- | ------------------------------------------------------------------------ | +| **CRITICAL** | 10-100x | Missing indexes, connection exhaustion, sequential scans on large tables | +| **HIGH** | 5-20x | Wrong index types, poor partitioning, missing covering indexes | +| **MEDIUM-HIGH** | 2-5x | N+1 queries, inefficient pagination, RLS optimization | +| **MEDIUM** | 1.5-3x | Redundant indexes, query plan instability | +| **LOW-MEDIUM** | 1.2-2x | VACUUM tuning, configuration tweaks | +| **LOW** | Incremental | Advanced patterns, edge cases | + +--- + +## Reference Standards + +**Primary Sources:** + +- Official Postgres documentation +- Supabase documentation +- Postgres wiki +- Established blogs (2ndQuadrant, Crunchy Data) + +**Format:** + +```markdown +Reference: +[Postgres Indexes](https://www.postgresql.org/docs/current/indexes.html) +``` + +--- + +## Review Checklist + +Before submitting a reference: + +- [ ] Title is clear and action-oriented +- [ ] Impact level matches the performance gain +- [ ] impactDescription includes quantification +- [ ] Explanation is concise (1-2 sentences) +- [ ] Has at least 1 **Incorrect** SQL example +- [ ] Has at least 1 **Correct** SQL example +- [ ] SQL uses semantic naming +- [ ] Comments explain _why_, not _what_ +- [ ] Trade-offs mentioned if applicable +- [ ] Reference links included +- [ ] `pnpm test` passes diff --git a/.agents/skills/supabase-postgres-best-practices/references/_sections.md b/.agents/skills/supabase-postgres-best-practices/references/_sections.md new file mode 100644 index 00000000..42c16e70 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/_sections.md @@ -0,0 +1,47 @@ +# Section Definitions + +This file defines the rule categories for Postgres best practices. Rules are automatically assigned to sections based on their filename prefix. + +Take the examples below as pure demonstrative. Replace each section with the actual rule categories for Postgres best practices. + +--- + +## 1. Query Performance (query) + +**Impact:** CRITICAL +**Description:** Slow queries, missing indexes, inefficient query plans. The most common source of Postgres performance issues. + +## 2. Connection Management (conn) + +**Impact:** CRITICAL +**Description:** Connection pooling, limits, and serverless strategies. Critical for applications with high concurrency or serverless deployments. + +## 3. Security & RLS (security) + +**Impact:** CRITICAL +**Description:** Row-Level Security policies, privilege management, and authentication patterns. + +## 4. Schema Design (schema) + +**Impact:** HIGH +**Description:** Table design, index strategies, partitioning, and data type selection. Foundation for long-term performance. + +## 5. Concurrency & Locking (lock) + +**Impact:** MEDIUM-HIGH +**Description:** Transaction management, isolation levels, deadlock prevention, and lock contention patterns. + +## 6. Data Access Patterns (data) + +**Impact:** MEDIUM +**Description:** N+1 query elimination, batch operations, cursor-based pagination, and efficient data fetching. + +## 7. Monitoring & Diagnostics (monitor) + +**Impact:** LOW-MEDIUM +**Description:** Using pg_stat_statements, EXPLAIN ANALYZE, metrics collection, and performance diagnostics. + +## 8. Advanced Features (advanced) + +**Impact:** LOW +**Description:** Full-text search, JSONB optimization, PostGIS, extensions, and advanced Postgres features. diff --git a/.agents/skills/supabase-postgres-best-practices/references/_template.md b/.agents/skills/supabase-postgres-best-practices/references/_template.md new file mode 100644 index 00000000..91ace90e --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/_template.md @@ -0,0 +1,34 @@ +--- +title: Clear, Action-Oriented Title (e.g., "Use Partial Indexes for Filtered Queries") +impact: MEDIUM +impactDescription: 5-20x query speedup for filtered queries +tags: indexes, query-optimization, performance +--- + +## [Rule Title] + +[1-2 sentence explanation of the problem and why it matters. Focus on performance impact.] + +**Incorrect (describe the problem):** + +```sql +-- Comment explaining what makes this slow/problematic +CREATE INDEX users_email_idx ON users(email); + +SELECT * FROM users WHERE email = 'user@example.com' AND deleted_at IS NULL; +-- This scans deleted records unnecessarily +``` + +**Correct (describe the solution):** + +```sql +-- Comment explaining why this is better +CREATE INDEX users_active_email_idx ON users(email) WHERE deleted_at IS NULL; + +SELECT * FROM users WHERE email = 'user@example.com' AND deleted_at IS NULL; +-- Only indexes active users, 10x smaller index, faster queries +``` + +[Optional: Additional context, edge cases, or trade-offs] + +Reference: [Postgres Docs](https://www.postgresql.org/docs/current/) diff --git a/.agents/skills/supabase-postgres-best-practices/references/advanced-full-text-search.md b/.agents/skills/supabase-postgres-best-practices/references/advanced-full-text-search.md new file mode 100644 index 00000000..582cbeaa --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/advanced-full-text-search.md @@ -0,0 +1,55 @@ +--- +title: Use tsvector for Full-Text Search +impact: MEDIUM +impactDescription: 100x faster than LIKE, with ranking support +tags: full-text-search, tsvector, gin, search +--- + +## Use tsvector for Full-Text Search + +LIKE with wildcards can't use indexes. Full-text search with tsvector is orders of magnitude faster. + +**Incorrect (LIKE pattern matching):** + +```sql +-- Cannot use index, scans all rows +select * from articles where content like '%postgresql%'; + +-- Case-insensitive makes it worse +select * from articles where lower(content) like '%postgresql%'; +``` + +**Correct (full-text search with tsvector):** + +```sql +-- Add tsvector column and index +alter table articles add column search_vector tsvector + generated always as (to_tsvector('english', coalesce(title,'') || ' ' || coalesce(content,''))) stored; + +create index articles_search_idx on articles using gin (search_vector); + +-- Fast full-text search +select * from articles +where search_vector @@ to_tsquery('english', 'postgresql & performance'); + +-- With ranking +select *, ts_rank(search_vector, query) as rank +from articles, to_tsquery('english', 'postgresql') query +where search_vector @@ query +order by rank desc; +``` + +Search multiple terms: + +```sql +-- AND: both terms required +to_tsquery('postgresql & performance') + +-- OR: either term +to_tsquery('postgresql | mysql') + +-- Prefix matching +to_tsquery('post:*') +``` + +Reference: [Full Text Search](https://supabase.com/docs/guides/database/full-text-search) diff --git a/.agents/skills/supabase-postgres-best-practices/references/advanced-jsonb-indexing.md b/.agents/skills/supabase-postgres-best-practices/references/advanced-jsonb-indexing.md new file mode 100644 index 00000000..e3d261ea --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/advanced-jsonb-indexing.md @@ -0,0 +1,49 @@ +--- +title: Index JSONB Columns for Efficient Querying +impact: MEDIUM +impactDescription: 10-100x faster JSONB queries with proper indexing +tags: jsonb, gin, indexes, json +--- + +## Index JSONB Columns for Efficient Querying + +JSONB queries without indexes scan the entire table. Use GIN indexes for containment queries. + +**Incorrect (no index on JSONB):** + +```sql +create table products ( + id bigint primary key, + attributes jsonb +); + +-- Full table scan for every query +select * from products where attributes @> '{"color": "red"}'; +select * from products where attributes->>'brand' = 'Nike'; +``` + +**Correct (GIN index for JSONB):** + +```sql +-- GIN index for containment operators (@>, ?, ?&, ?|) +create index products_attrs_gin on products using gin (attributes); + +-- Now containment queries use the index +select * from products where attributes @> '{"color": "red"}'; + +-- For specific key lookups, use expression index +create index products_brand_idx on products ((attributes->>'brand')); +select * from products where attributes->>'brand' = 'Nike'; +``` + +Choose the right operator class: + +```sql +-- jsonb_ops (default): supports all operators, larger index +create index idx1 on products using gin (attributes); + +-- jsonb_path_ops: only @> operator, but 2-3x smaller index +create index idx2 on products using gin (attributes jsonb_path_ops); +``` + +Reference: [JSONB Indexes](https://www.postgresql.org/docs/current/datatype-json.html#JSON-INDEXING) diff --git a/.agents/skills/supabase-postgres-best-practices/references/conn-idle-timeout.md b/.agents/skills/supabase-postgres-best-practices/references/conn-idle-timeout.md new file mode 100644 index 00000000..40b9cc50 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/conn-idle-timeout.md @@ -0,0 +1,46 @@ +--- +title: Configure Idle Connection Timeouts +impact: HIGH +impactDescription: Reclaim 30-50% of connection slots from idle clients +tags: connections, timeout, idle, resource-management +--- + +## Configure Idle Connection Timeouts + +Idle connections waste resources. Configure timeouts to automatically reclaim them. + +**Incorrect (connections held indefinitely):** + +```sql +-- No timeout configured +show idle_in_transaction_session_timeout; -- 0 (disabled) + +-- Connections stay open forever, even when idle +select pid, state, state_change, query +from pg_stat_activity +where state = 'idle in transaction'; +-- Shows transactions idle for hours, holding locks +``` + +**Correct (automatic cleanup of idle connections):** + +```sql +-- Terminate connections idle in transaction after 30 seconds +alter system set idle_in_transaction_session_timeout = '30s'; + +-- Terminate completely idle connections after 10 minutes +alter system set idle_session_timeout = '10min'; + +-- Reload configuration +select pg_reload_conf(); +``` + +For pooled connections, configure at the pooler level: + +```ini +# pgbouncer.ini +server_idle_timeout = 60 +client_idle_timeout = 300 +``` + +Reference: [Connection Timeouts](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-IDLE-IN-TRANSACTION-SESSION-TIMEOUT) diff --git a/.agents/skills/supabase-postgres-best-practices/references/conn-limits.md b/.agents/skills/supabase-postgres-best-practices/references/conn-limits.md new file mode 100644 index 00000000..cb3e400c --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/conn-limits.md @@ -0,0 +1,44 @@ +--- +title: Set Appropriate Connection Limits +impact: CRITICAL +impactDescription: Prevent database crashes and memory exhaustion +tags: connections, max-connections, limits, stability +--- + +## Set Appropriate Connection Limits + +Too many connections exhaust memory and degrade performance. Set limits based on available resources. + +**Incorrect (unlimited or excessive connections):** + +```sql +-- Default max_connections = 100, but often increased blindly +show max_connections; -- 500 (way too high for 4GB RAM) + +-- Each connection uses 1-3MB RAM +-- 500 connections * 2MB = 1GB just for connections! +-- Out of memory errors under load +``` + +**Correct (calculate based on resources):** + +```sql +-- Formula: max_connections = (RAM in MB / 5MB per connection) - reserved +-- For 4GB RAM: (4096 / 5) - 10 = ~800 theoretical max +-- But practically, 100-200 is better for query performance + +-- Recommended settings for 4GB RAM +alter system set max_connections = 100; + +-- Also set work_mem appropriately +-- work_mem * max_connections should not exceed 25% of RAM +alter system set work_mem = '8MB'; -- 8MB * 100 = 800MB max +``` + +Monitor connection usage: + +```sql +select count(*), state from pg_stat_activity group by state; +``` + +Reference: [Database Connections](https://supabase.com/docs/guides/platform/performance#connection-management) diff --git a/.agents/skills/supabase-postgres-best-practices/references/conn-pooling.md b/.agents/skills/supabase-postgres-best-practices/references/conn-pooling.md new file mode 100644 index 00000000..e2ebd581 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/conn-pooling.md @@ -0,0 +1,41 @@ +--- +title: Use Connection Pooling for All Applications +impact: CRITICAL +impactDescription: Handle 10-100x more concurrent users +tags: connection-pooling, pgbouncer, performance, scalability +--- + +## Use Connection Pooling for All Applications + +Postgres connections are expensive (1-3MB RAM each). Without pooling, applications exhaust connections under load. + +**Incorrect (new connection per request):** + +```sql +-- Each request creates a new connection +-- Application code: db.connect() per request +-- Result: 500 concurrent users = 500 connections = crashed database + +-- Check current connections +select count(*) from pg_stat_activity; -- 487 connections! +``` + +**Correct (connection pooling):** + +```sql +-- Use a pooler like PgBouncer between app and database +-- Application connects to pooler, pooler reuses a small pool to Postgres + +-- Configure pool_size based on: (CPU cores * 2) + spindle_count +-- Example for 4 cores: pool_size = 10 + +-- Result: 500 concurrent users share 10 actual connections +select count(*) from pg_stat_activity; -- 10 connections +``` + +Pool modes: + +- **Transaction mode**: connection returned after each transaction (best for most apps) +- **Session mode**: connection held for entire session (needed for prepared statements, temp tables) + +Reference: [Connection Pooling](https://supabase.com/docs/guides/database/connecting-to-postgres#connection-pooler) diff --git a/.agents/skills/supabase-postgres-best-practices/references/conn-prepared-statements.md b/.agents/skills/supabase-postgres-best-practices/references/conn-prepared-statements.md new file mode 100644 index 00000000..555547d8 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/conn-prepared-statements.md @@ -0,0 +1,46 @@ +--- +title: Use Prepared Statements Correctly with Pooling +impact: HIGH +impactDescription: Avoid prepared statement conflicts in pooled environments +tags: prepared-statements, connection-pooling, transaction-mode +--- + +## Use Prepared Statements Correctly with Pooling + +Prepared statements are tied to individual database connections. In transaction-mode pooling, connections are shared, causing conflicts. + +**Incorrect (named prepared statements with transaction pooling):** + +```sql +-- Named prepared statement +prepare get_user as select * from users where id = $1; + +-- In transaction mode pooling, next request may get different connection +execute get_user(123); +-- ERROR: prepared statement "get_user" does not exist +``` + +**Correct (use unnamed statements or session mode):** + +```sql +-- Option 1: Use unnamed prepared statements (most ORMs do this automatically) +-- The query is prepared and executed in a single protocol message + +-- Option 2: Deallocate after use in transaction mode +prepare get_user as select * from users where id = $1; +execute get_user(123); +deallocate get_user; + +-- Option 3: Use session mode pooling (port 5432 vs 6543) +-- Connection is held for entire session, prepared statements persist +``` + +Check your driver settings: + +```sql +-- Many drivers use prepared statements by default +-- Node.js pg: { prepare: false } to disable +-- JDBC: prepareThreshold=0 to disable +``` + +Reference: [Prepared Statements with Pooling](https://supabase.com/docs/guides/database/connecting-to-postgres#connection-pool-modes) diff --git a/.agents/skills/supabase-postgres-best-practices/references/data-batch-inserts.md b/.agents/skills/supabase-postgres-best-practices/references/data-batch-inserts.md new file mode 100644 index 00000000..997947cb --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/data-batch-inserts.md @@ -0,0 +1,54 @@ +--- +title: Batch INSERT Statements for Bulk Data +impact: MEDIUM +impactDescription: 10-50x faster bulk inserts +tags: batch, insert, bulk, performance, copy +--- + +## Batch INSERT Statements for Bulk Data + +Individual INSERT statements have high overhead. Batch multiple rows in single statements or use COPY. + +**Incorrect (individual inserts):** + +```sql +-- Each insert is a separate transaction and round trip +insert into events (user_id, action) values (1, 'click'); +insert into events (user_id, action) values (1, 'view'); +insert into events (user_id, action) values (2, 'click'); +-- ... 1000 more individual inserts + +-- 1000 inserts = 1000 round trips = slow +``` + +**Correct (batch insert):** + +```sql +-- Multiple rows in single statement +insert into events (user_id, action) values + (1, 'click'), + (1, 'view'), + (2, 'click'), + -- ... up to ~1000 rows per batch + (999, 'view'); + +-- One round trip for 1000 rows +``` + +For large imports, use COPY: + +```sql +-- COPY is fastest for bulk loading +copy events (user_id, action, created_at) +from '/path/to/data.csv' +with (format csv, header true); + +-- Or from stdin in application +copy events (user_id, action) from stdin with (format csv); +1,click +1,view +2,click +\. +``` + +Reference: [COPY](https://www.postgresql.org/docs/current/sql-copy.html) diff --git a/.agents/skills/supabase-postgres-best-practices/references/data-n-plus-one.md b/.agents/skills/supabase-postgres-best-practices/references/data-n-plus-one.md new file mode 100644 index 00000000..2109186f --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/data-n-plus-one.md @@ -0,0 +1,53 @@ +--- +title: Eliminate N+1 Queries with Batch Loading +impact: MEDIUM-HIGH +impactDescription: 10-100x fewer database round trips +tags: n-plus-one, batch, performance, queries +--- + +## Eliminate N+1 Queries with Batch Loading + +N+1 queries execute one query per item in a loop. Batch them into a single query using arrays or JOINs. + +**Incorrect (N+1 queries):** + +```sql +-- First query: get all users +select id from users where active = true; -- Returns 100 IDs + +-- Then N queries, one per user +select * from orders where user_id = 1; +select * from orders where user_id = 2; +select * from orders where user_id = 3; +-- ... 97 more queries! + +-- Total: 101 round trips to database +``` + +**Correct (single batch query):** + +```sql +-- Collect IDs and query once with ANY +select * from orders where user_id = any(array[1, 2, 3, ...]); + +-- Or use JOIN instead of loop +select u.id, u.name, o.* +from users u +left join orders o on o.user_id = u.id +where u.active = true; + +-- Total: 1 round trip +``` + +Application pattern: + +```sql +-- Instead of looping in application code: +-- for user in users: db.query("SELECT * FROM orders WHERE user_id = $1", user.id) + +-- Pass array parameter: +select * from orders where user_id = any($1::bigint[]); +-- Application passes: [1, 2, 3, 4, 5, ...] +``` + +Reference: [N+1 Query Problem](https://supabase.com/docs/guides/database/query-optimization) diff --git a/.agents/skills/supabase-postgres-best-practices/references/data-pagination.md b/.agents/skills/supabase-postgres-best-practices/references/data-pagination.md new file mode 100644 index 00000000..633d8393 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/data-pagination.md @@ -0,0 +1,50 @@ +--- +title: Use Cursor-Based Pagination Instead of OFFSET +impact: MEDIUM-HIGH +impactDescription: Consistent O(1) performance regardless of page depth +tags: pagination, cursor, keyset, offset, performance +--- + +## Use Cursor-Based Pagination Instead of OFFSET + +OFFSET-based pagination scans all skipped rows, getting slower on deeper pages. Cursor pagination is O(1). + +**Incorrect (OFFSET pagination):** + +```sql +-- Page 1: scans 20 rows +select * from products order by id limit 20 offset 0; + +-- Page 100: scans 2000 rows to skip 1980 +select * from products order by id limit 20 offset 1980; + +-- Page 10000: scans 200,000 rows! +select * from products order by id limit 20 offset 199980; +``` + +**Correct (cursor/keyset pagination):** + +```sql +-- Page 1: get first 20 +select * from products order by id limit 20; +-- Application stores last_id = 20 + +-- Page 2: start after last ID +select * from products where id > 20 order by id limit 20; +-- Uses index, always fast regardless of page depth + +-- Page 10000: same speed as page 1 +select * from products where id > 199980 order by id limit 20; +``` + +For multi-column sorting: + +```sql +-- Cursor must include all sort columns +select * from products +where (created_at, id) > ('2024-01-15 10:00:00', 12345) +order by created_at, id +limit 20; +``` + +Reference: [Pagination](https://supabase.com/docs/guides/database/pagination) diff --git a/.agents/skills/supabase-postgres-best-practices/references/data-upsert.md b/.agents/skills/supabase-postgres-best-practices/references/data-upsert.md new file mode 100644 index 00000000..bc95e230 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/data-upsert.md @@ -0,0 +1,50 @@ +--- +title: Use UPSERT for Insert-or-Update Operations +impact: MEDIUM +impactDescription: Atomic operation, eliminates race conditions +tags: upsert, on-conflict, insert, update +--- + +## Use UPSERT for Insert-or-Update Operations + +Using separate SELECT-then-INSERT/UPDATE creates race conditions. Use INSERT ... ON CONFLICT for atomic upserts. + +**Incorrect (check-then-insert race condition):** + +```sql +-- Race condition: two requests check simultaneously +select * from settings where user_id = 123 and key = 'theme'; +-- Both find nothing + +-- Both try to insert +insert into settings (user_id, key, value) values (123, 'theme', 'dark'); +-- One succeeds, one fails with duplicate key error! +``` + +**Correct (atomic UPSERT):** + +```sql +-- Single atomic operation +insert into settings (user_id, key, value) +values (123, 'theme', 'dark') +on conflict (user_id, key) +do update set value = excluded.value, updated_at = now(); + +-- Returns the inserted/updated row +insert into settings (user_id, key, value) +values (123, 'theme', 'dark') +on conflict (user_id, key) +do update set value = excluded.value +returning *; +``` + +Insert-or-ignore pattern: + +```sql +-- Insert only if not exists (no update) +insert into page_views (page_id, user_id) +values (1, 123) +on conflict (page_id, user_id) do nothing; +``` + +Reference: [INSERT ON CONFLICT](https://www.postgresql.org/docs/current/sql-insert.html#SQL-ON-CONFLICT) diff --git a/.agents/skills/supabase-postgres-best-practices/references/lock-advisory.md b/.agents/skills/supabase-postgres-best-practices/references/lock-advisory.md new file mode 100644 index 00000000..572eaf0d --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/lock-advisory.md @@ -0,0 +1,56 @@ +--- +title: Use Advisory Locks for Application-Level Locking +impact: MEDIUM +impactDescription: Efficient coordination without row-level lock overhead +tags: advisory-locks, coordination, application-locks +--- + +## Use Advisory Locks for Application-Level Locking + +Advisory locks provide application-level coordination without requiring database rows to lock. + +**Incorrect (creating rows just for locking):** + +```sql +-- Creating dummy rows to lock on +create table resource_locks ( + resource_name text primary key +); + +insert into resource_locks values ('report_generator'); + +-- Lock by selecting the row +select * from resource_locks where resource_name = 'report_generator' for update; +``` + +**Correct (advisory locks):** + +```sql +-- Session-level advisory lock (released on disconnect or unlock) +select pg_advisory_lock(hashtext('report_generator')); +-- ... do exclusive work ... +select pg_advisory_unlock(hashtext('report_generator')); + +-- Transaction-level lock (released on commit/rollback) +begin; +select pg_advisory_xact_lock(hashtext('daily_report')); +-- ... do work ... +commit; -- Lock automatically released +``` + +Try-lock for non-blocking operations: + +```sql +-- Returns immediately with true/false instead of waiting +select pg_try_advisory_lock(hashtext('resource_name')); + +-- Use in application +if (acquired) { + -- Do work + select pg_advisory_unlock(hashtext('resource_name')); +} else { + -- Skip or retry later +} +``` + +Reference: [Advisory Locks](https://www.postgresql.org/docs/current/explicit-locking.html#ADVISORY-LOCKS) diff --git a/.agents/skills/supabase-postgres-best-practices/references/lock-deadlock-prevention.md b/.agents/skills/supabase-postgres-best-practices/references/lock-deadlock-prevention.md new file mode 100644 index 00000000..974da5ed --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/lock-deadlock-prevention.md @@ -0,0 +1,68 @@ +--- +title: Prevent Deadlocks with Consistent Lock Ordering +impact: MEDIUM-HIGH +impactDescription: Eliminate deadlock errors, improve reliability +tags: deadlocks, locking, transactions, ordering +--- + +## Prevent Deadlocks with Consistent Lock Ordering + +Deadlocks occur when transactions lock resources in different orders. Always +acquire locks in a consistent order. + +**Incorrect (inconsistent lock ordering):** + +```sql +-- Transaction A -- Transaction B +begin; begin; +update accounts update accounts +set balance = balance - 100 set balance = balance - 50 +where id = 1; where id = 2; -- B locks row 2 + +update accounts update accounts +set balance = balance + 100 set balance = balance + 50 +where id = 2; -- A waits for B where id = 1; -- B waits for A + +-- DEADLOCK! Both waiting for each other +``` + +**Correct (lock rows in consistent order first):** + +```sql +-- Explicitly acquire locks in ID order before updating +begin; +select * from accounts where id in (1, 2) order by id for update; + +-- Now perform updates in any order - locks already held +update accounts set balance = balance - 100 where id = 1; +update accounts set balance = balance + 100 where id = 2; +commit; +``` + +Alternative: use a single statement to update atomically: + +```sql +-- Single statement acquires all locks atomically +begin; +update accounts +set balance = balance + case id + when 1 then -100 + when 2 then 100 +end +where id in (1, 2); +commit; +``` + +Detect deadlocks in logs: + +```sql +-- Check for recent deadlocks +select * from pg_stat_database where deadlocks > 0; + +-- Enable deadlock logging +set log_lock_waits = on; +set deadlock_timeout = '1s'; +``` + +Reference: +[Deadlocks](https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-DEADLOCKS) diff --git a/.agents/skills/supabase-postgres-best-practices/references/lock-short-transactions.md b/.agents/skills/supabase-postgres-best-practices/references/lock-short-transactions.md new file mode 100644 index 00000000..e6b8ef26 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/lock-short-transactions.md @@ -0,0 +1,50 @@ +--- +title: Keep Transactions Short to Reduce Lock Contention +impact: MEDIUM-HIGH +impactDescription: 3-5x throughput improvement, fewer deadlocks +tags: transactions, locking, contention, performance +--- + +## Keep Transactions Short to Reduce Lock Contention + +Long-running transactions hold locks that block other queries. Keep transactions as short as possible. + +**Incorrect (long transaction with external calls):** + +```sql +begin; +select * from orders where id = 1 for update; -- Lock acquired + +-- Application makes HTTP call to payment API (2-5 seconds) +-- Other queries on this row are blocked! + +update orders set status = 'paid' where id = 1; +commit; -- Lock held for entire duration +``` + +**Correct (minimal transaction scope):** + +```sql +-- Validate data and call APIs outside transaction +-- Application: response = await paymentAPI.charge(...) + +-- Only hold lock for the actual update +begin; +update orders +set status = 'paid', payment_id = $1 +where id = $2 and status = 'pending' +returning *; +commit; -- Lock held for milliseconds +``` + +Use `statement_timeout` to prevent runaway transactions: + +```sql +-- Abort queries running longer than 30 seconds +set statement_timeout = '30s'; + +-- Or per-session +set local statement_timeout = '5s'; +``` + +Reference: [Transaction Management](https://www.postgresql.org/docs/current/tutorial-transactions.html) diff --git a/.agents/skills/supabase-postgres-best-practices/references/lock-skip-locked.md b/.agents/skills/supabase-postgres-best-practices/references/lock-skip-locked.md new file mode 100644 index 00000000..77bdbb97 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/lock-skip-locked.md @@ -0,0 +1,54 @@ +--- +title: Use SKIP LOCKED for Non-Blocking Queue Processing +impact: MEDIUM-HIGH +impactDescription: 10x throughput for worker queues +tags: skip-locked, queue, workers, concurrency +--- + +## Use SKIP LOCKED for Non-Blocking Queue Processing + +When multiple workers process a queue, SKIP LOCKED allows workers to process different rows without waiting. + +**Incorrect (workers block each other):** + +```sql +-- Worker 1 and Worker 2 both try to get next job +begin; +select * from jobs where status = 'pending' order by created_at limit 1 for update; +-- Worker 2 waits for Worker 1's lock to release! +``` + +**Correct (SKIP LOCKED for parallel processing):** + +```sql +-- Each worker skips locked rows and gets the next available +begin; +select * from jobs +where status = 'pending' +order by created_at +limit 1 +for update skip locked; + +-- Worker 1 gets job 1, Worker 2 gets job 2 (no waiting) + +update jobs set status = 'processing' where id = $1; +commit; +``` + +Complete queue pattern: + +```sql +-- Atomic claim-and-update in one statement +update jobs +set status = 'processing', worker_id = $1, started_at = now() +where id = ( + select id from jobs + where status = 'pending' + order by created_at + limit 1 + for update skip locked +) +returning *; +``` + +Reference: [SELECT FOR UPDATE SKIP LOCKED](https://www.postgresql.org/docs/current/sql-select.html#SQL-FOR-UPDATE-SHARE) diff --git a/.agents/skills/supabase-postgres-best-practices/references/monitor-explain-analyze.md b/.agents/skills/supabase-postgres-best-practices/references/monitor-explain-analyze.md new file mode 100644 index 00000000..542978c3 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/monitor-explain-analyze.md @@ -0,0 +1,45 @@ +--- +title: Use EXPLAIN ANALYZE to Diagnose Slow Queries +impact: LOW-MEDIUM +impactDescription: Identify exact bottlenecks in query execution +tags: explain, analyze, diagnostics, query-plan +--- + +## Use EXPLAIN ANALYZE to Diagnose Slow Queries + +EXPLAIN ANALYZE executes the query and shows actual timings, revealing the true performance bottlenecks. + +**Incorrect (guessing at performance issues):** + +```sql +-- Query is slow, but why? +select * from orders where customer_id = 123 and status = 'pending'; +-- "It must be missing an index" - but which one? +``` + +**Correct (use EXPLAIN ANALYZE):** + +```sql +explain (analyze, buffers, format text) +select * from orders where customer_id = 123 and status = 'pending'; + +-- Output reveals the issue: +-- Seq Scan on orders (cost=0.00..25000.00 rows=50 width=100) (actual time=0.015..450.123 rows=50 loops=1) +-- Filter: ((customer_id = 123) AND (status = 'pending'::text)) +-- Rows Removed by Filter: 999950 +-- Buffers: shared hit=5000 read=15000 +-- Planning Time: 0.150 ms +-- Execution Time: 450.500 ms +``` + +Key things to look for: + +```sql +-- Seq Scan on large tables = missing index +-- Rows Removed by Filter = poor selectivity or missing index +-- Buffers: read >> hit = data not cached, needs more memory +-- Nested Loop with high loops = consider different join strategy +-- Sort Method: external merge = work_mem too low +``` + +Reference: [EXPLAIN](https://supabase.com/docs/guides/database/inspect) diff --git a/.agents/skills/supabase-postgres-best-practices/references/monitor-pg-stat-statements.md b/.agents/skills/supabase-postgres-best-practices/references/monitor-pg-stat-statements.md new file mode 100644 index 00000000..d7e82f1a --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/monitor-pg-stat-statements.md @@ -0,0 +1,55 @@ +--- +title: Enable pg_stat_statements for Query Analysis +impact: LOW-MEDIUM +impactDescription: Identify top resource-consuming queries +tags: pg-stat-statements, monitoring, statistics, performance +--- + +## Enable pg_stat_statements for Query Analysis + +pg_stat_statements tracks execution statistics for all queries, helping identify slow and frequent queries. + +**Incorrect (no visibility into query patterns):** + +```sql +-- Database is slow, but which queries are the problem? +-- No way to know without pg_stat_statements +``` + +**Correct (enable and query pg_stat_statements):** + +```sql +-- Enable the extension +create extension if not exists pg_stat_statements; + +-- Find slowest queries by total time +select + calls, + round(total_exec_time::numeric, 2) as total_time_ms, + round(mean_exec_time::numeric, 2) as mean_time_ms, + query +from pg_stat_statements +order by total_exec_time desc +limit 10; + +-- Find most frequent queries +select calls, query +from pg_stat_statements +order by calls desc +limit 10; + +-- Reset statistics after optimization +select pg_stat_statements_reset(); +``` + +Key metrics to monitor: + +```sql +-- Queries with high mean time (candidates for optimization) +select query, mean_exec_time, calls +from pg_stat_statements +where mean_exec_time > 100 -- > 100ms average +order by mean_exec_time desc; +``` + +Reference: [pg_stat_statements](https://supabase.com/docs/guides/database/extensions/pg_stat_statements) diff --git a/.agents/skills/supabase-postgres-best-practices/references/monitor-vacuum-analyze.md b/.agents/skills/supabase-postgres-best-practices/references/monitor-vacuum-analyze.md new file mode 100644 index 00000000..e0e8ea0b --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/monitor-vacuum-analyze.md @@ -0,0 +1,55 @@ +--- +title: Maintain Table Statistics with VACUUM and ANALYZE +impact: MEDIUM +impactDescription: 2-10x better query plans with accurate statistics +tags: vacuum, analyze, statistics, maintenance, autovacuum +--- + +## Maintain Table Statistics with VACUUM and ANALYZE + +Outdated statistics cause the query planner to make poor decisions. VACUUM reclaims space, ANALYZE updates statistics. + +**Incorrect (stale statistics):** + +```sql +-- Table has 1M rows but stats say 1000 +-- Query planner chooses wrong strategy +explain select * from orders where status = 'pending'; +-- Shows: Seq Scan (because stats show small table) +-- Actually: Index Scan would be much faster +``` + +**Correct (maintain fresh statistics):** + +```sql +-- Manually analyze after large data changes +analyze orders; + +-- Analyze specific columns used in WHERE clauses +analyze orders (status, created_at); + +-- Check when tables were last analyzed +select + relname, + last_vacuum, + last_autovacuum, + last_analyze, + last_autoanalyze +from pg_stat_user_tables +order by last_analyze nulls first; +``` + +Autovacuum tuning for busy tables: + +```sql +-- Increase frequency for high-churn tables +alter table orders set ( + autovacuum_vacuum_scale_factor = 0.05, -- Vacuum at 5% dead tuples (default 20%) + autovacuum_analyze_scale_factor = 0.02 -- Analyze at 2% changes (default 10%) +); + +-- Check autovacuum status +select * from pg_stat_progress_vacuum; +``` + +Reference: [VACUUM](https://supabase.com/docs/guides/database/database-size#vacuum-operations) diff --git a/.agents/skills/supabase-postgres-best-practices/references/query-composite-indexes.md b/.agents/skills/supabase-postgres-best-practices/references/query-composite-indexes.md new file mode 100644 index 00000000..fea64523 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/query-composite-indexes.md @@ -0,0 +1,44 @@ +--- +title: Create Composite Indexes for Multi-Column Queries +impact: HIGH +impactDescription: 5-10x faster multi-column queries +tags: indexes, composite-index, multi-column, query-optimization +--- + +## Create Composite Indexes for Multi-Column Queries + +When queries filter on multiple columns, a composite index is more efficient than separate single-column indexes. + +**Incorrect (separate indexes require bitmap scan):** + +```sql +-- Two separate indexes +create index orders_status_idx on orders (status); +create index orders_created_idx on orders (created_at); + +-- Query must combine both indexes (slower) +select * from orders where status = 'pending' and created_at > '2024-01-01'; +``` + +**Correct (composite index):** + +```sql +-- Single composite index (leftmost column first for equality checks) +create index orders_status_created_idx on orders (status, created_at); + +-- Query uses one efficient index scan +select * from orders where status = 'pending' and created_at > '2024-01-01'; +``` + +**Column order matters** - place equality columns first, range columns last: + +```sql +-- Good: status (=) before created_at (>) +create index idx on orders (status, created_at); + +-- Works for: WHERE status = 'pending' +-- Works for: WHERE status = 'pending' AND created_at > '2024-01-01' +-- Does NOT work for: WHERE created_at > '2024-01-01' (leftmost prefix rule) +``` + +Reference: [Multicolumn Indexes](https://www.postgresql.org/docs/current/indexes-multicolumn.html) diff --git a/.agents/skills/supabase-postgres-best-practices/references/query-covering-indexes.md b/.agents/skills/supabase-postgres-best-practices/references/query-covering-indexes.md new file mode 100644 index 00000000..9d2a4947 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/query-covering-indexes.md @@ -0,0 +1,40 @@ +--- +title: Use Covering Indexes to Avoid Table Lookups +impact: MEDIUM-HIGH +impactDescription: 2-5x faster queries by eliminating heap fetches +tags: indexes, covering-index, include, index-only-scan +--- + +## Use Covering Indexes to Avoid Table Lookups + +Covering indexes include all columns needed by a query, enabling index-only scans that skip the table entirely. + +**Incorrect (index scan + heap fetch):** + +```sql +create index users_email_idx on users (email); + +-- Must fetch name and created_at from table heap +select email, name, created_at from users where email = 'user@example.com'; +``` + +**Correct (index-only scan with INCLUDE):** + +```sql +-- Include non-searchable columns in the index +create index users_email_idx on users (email) include (name, created_at); + +-- All columns served from index, no table access needed +select email, name, created_at from users where email = 'user@example.com'; +``` + +Use INCLUDE for columns you SELECT but don't filter on: + +```sql +-- Searching by status, but also need customer_id and total +create index orders_status_idx on orders (status) include (customer_id, total); + +select status, customer_id, total from orders where status = 'shipped'; +``` + +Reference: [Index-Only Scans](https://www.postgresql.org/docs/current/indexes-index-only-scans.html) diff --git a/.agents/skills/supabase-postgres-best-practices/references/query-index-types.md b/.agents/skills/supabase-postgres-best-practices/references/query-index-types.md new file mode 100644 index 00000000..93b32590 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/query-index-types.md @@ -0,0 +1,48 @@ +--- +title: Choose the Right Index Type for Your Data +impact: HIGH +impactDescription: 10-100x improvement with correct index type +tags: indexes, btree, gin, gist, brin, hash, index-types +--- + +## Choose the Right Index Type for Your Data + +Different index types excel at different query patterns. The default B-tree isn't always optimal. + +**Incorrect (B-tree for JSONB containment):** + +```sql +-- B-tree cannot optimize containment operators +create index products_attrs_idx on products (attributes); +select * from products where attributes @> '{"color": "red"}'; +-- Full table scan - B-tree doesn't support @> operator +``` + +**Correct (GIN for JSONB):** + +```sql +-- GIN supports @>, ?, ?&, ?| operators +create index products_attrs_idx on products using gin (attributes); +select * from products where attributes @> '{"color": "red"}'; +``` + +Index type guide: + +```sql +-- B-tree (default): =, <, >, BETWEEN, IN, IS NULL +create index users_created_idx on users (created_at); + +-- GIN: arrays, JSONB, full-text search +create index posts_tags_idx on posts using gin (tags); + +-- GiST: geometric data, range types, nearest-neighbor (KNN) queries +create index locations_idx on places using gist (location); + +-- BRIN: large time-series tables (10-100x smaller) +create index events_time_idx on events using brin (created_at); + +-- Hash: equality-only (slightly faster than B-tree for =) +create index sessions_token_idx on sessions using hash (token); +``` + +Reference: [Index Types](https://www.postgresql.org/docs/current/indexes-types.html) diff --git a/.agents/skills/supabase-postgres-best-practices/references/query-missing-indexes.md b/.agents/skills/supabase-postgres-best-practices/references/query-missing-indexes.md new file mode 100644 index 00000000..e6daace7 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/query-missing-indexes.md @@ -0,0 +1,43 @@ +--- +title: Add Indexes on WHERE and JOIN Columns +impact: CRITICAL +impactDescription: 100-1000x faster queries on large tables +tags: indexes, performance, sequential-scan, query-optimization +--- + +## Add Indexes on WHERE and JOIN Columns + +Queries filtering or joining on unindexed columns cause full table scans, which become exponentially slower as tables grow. + +**Incorrect (sequential scan on large table):** + +```sql +-- No index on customer_id causes full table scan +select * from orders where customer_id = 123; + +-- EXPLAIN shows: Seq Scan on orders (cost=0.00..25000.00 rows=100 width=85) +``` + +**Correct (index scan):** + +```sql +-- Create index on frequently filtered column +create index orders_customer_id_idx on orders (customer_id); + +select * from orders where customer_id = 123; + +-- EXPLAIN shows: Index Scan using orders_customer_id_idx (cost=0.42..8.44 rows=100 width=85) +``` + +For JOIN columns, always index the foreign key side: + +```sql +-- Index the referencing column +create index orders_customer_id_idx on orders (customer_id); + +select c.name, o.total +from customers c +join orders o on o.customer_id = c.id; +``` + +Reference: [Query Optimization](https://supabase.com/docs/guides/database/query-optimization) diff --git a/.agents/skills/supabase-postgres-best-practices/references/query-partial-indexes.md b/.agents/skills/supabase-postgres-best-practices/references/query-partial-indexes.md new file mode 100644 index 00000000..3e61a341 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/query-partial-indexes.md @@ -0,0 +1,45 @@ +--- +title: Use Partial Indexes for Filtered Queries +impact: HIGH +impactDescription: 5-20x smaller indexes, faster writes and queries +tags: indexes, partial-index, query-optimization, storage +--- + +## Use Partial Indexes for Filtered Queries + +Partial indexes only include rows matching a WHERE condition, making them smaller and faster when queries consistently filter on the same condition. + +**Incorrect (full index includes irrelevant rows):** + +```sql +-- Index includes all rows, even soft-deleted ones +create index users_email_idx on users (email); + +-- Query always filters active users +select * from users where email = 'user@example.com' and deleted_at is null; +``` + +**Correct (partial index matches query filter):** + +```sql +-- Index only includes active users +create index users_active_email_idx on users (email) +where deleted_at is null; + +-- Query uses the smaller, faster index +select * from users where email = 'user@example.com' and deleted_at is null; +``` + +Common use cases for partial indexes: + +```sql +-- Only pending orders (status rarely changes once completed) +create index orders_pending_idx on orders (created_at) +where status = 'pending'; + +-- Only non-null values +create index products_sku_idx on products (sku) +where sku is not null; +``` + +Reference: [Partial Indexes](https://www.postgresql.org/docs/current/indexes-partial.html) diff --git a/.agents/skills/supabase-postgres-best-practices/references/schema-constraints.md b/.agents/skills/supabase-postgres-best-practices/references/schema-constraints.md new file mode 100644 index 00000000..1d2ef8f9 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/schema-constraints.md @@ -0,0 +1,80 @@ +--- +title: Add Constraints Safely in Migrations +impact: HIGH +impactDescription: Prevents migration failures and enables idempotent schema changes +tags: constraints, migrations, schema, alter-table +--- + +## Add Constraints Safely in Migrations + +PostgreSQL does not support `ADD CONSTRAINT IF NOT EXISTS`. Migrations using this syntax will fail. + +**Incorrect (causes syntax error):** + +```sql +-- ERROR: syntax error at or near "not" (SQLSTATE 42601) +alter table public.profiles +add constraint if not exists profiles_birthchart_id_unique unique (birthchart_id); +``` + +**Correct (idempotent constraint creation):** + +```sql +-- Use DO block to check before adding +do $$ +begin + if not exists ( + select 1 from pg_constraint + where conname = 'profiles_birthchart_id_unique' + and conrelid = 'public.profiles'::regclass + ) then + alter table public.profiles + add constraint profiles_birthchart_id_unique unique (birthchart_id); + end if; +end $$; +``` + +For all constraint types: + +```sql +-- Check constraints +do $$ +begin + if not exists ( + select 1 from pg_constraint + where conname = 'check_age_positive' + ) then + alter table users add constraint check_age_positive check (age > 0); + end if; +end $$; + +-- Foreign keys +do $$ +begin + if not exists ( + select 1 from pg_constraint + where conname = 'profiles_birthchart_id_fkey' + ) then + alter table profiles + add constraint profiles_birthchart_id_fkey + foreign key (birthchart_id) references birthcharts(id); + end if; +end $$; +``` + +Check if constraint exists: + +```sql +-- Query to check constraint existence +select conname, contype, pg_get_constraintdef(oid) +from pg_constraint +where conrelid = 'public.profiles'::regclass; + +-- contype values: +-- 'p' = PRIMARY KEY +-- 'f' = FOREIGN KEY +-- 'u' = UNIQUE +-- 'c' = CHECK +``` + +Reference: [Constraints](https://www.postgresql.org/docs/current/ddl-constraints.html) diff --git a/.agents/skills/supabase-postgres-best-practices/references/schema-data-types.md b/.agents/skills/supabase-postgres-best-practices/references/schema-data-types.md new file mode 100644 index 00000000..f253a581 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/schema-data-types.md @@ -0,0 +1,46 @@ +--- +title: Choose Appropriate Data Types +impact: HIGH +impactDescription: 50% storage reduction, faster comparisons +tags: data-types, schema, storage, performance +--- + +## Choose Appropriate Data Types + +Using the right data types reduces storage, improves query performance, and prevents bugs. + +**Incorrect (wrong data types):** + +```sql +create table users ( + id int, -- Will overflow at 2.1 billion + email varchar(255), -- Unnecessary length limit + created_at timestamp, -- Missing timezone info + is_active varchar(5), -- String for boolean + price varchar(20) -- String for numeric +); +``` + +**Correct (appropriate data types):** + +```sql +create table users ( + id bigint generated always as identity primary key, -- 9 quintillion max + email text, -- No artificial limit, same performance as varchar + created_at timestamptz, -- Always store timezone-aware timestamps + is_active boolean default true, -- 1 byte vs variable string length + price numeric(10,2) -- Exact decimal arithmetic +); +``` + +Key guidelines: + +```sql +-- IDs: use bigint, not int (future-proofing) +-- Strings: use text, not varchar(n) unless constraint needed +-- Time: use timestamptz, not timestamp +-- Money: use numeric, not float (precision matters) +-- Enums: use text with check constraint or create enum type +``` + +Reference: [Data Types](https://www.postgresql.org/docs/current/datatype.html) diff --git a/.agents/skills/supabase-postgres-best-practices/references/schema-foreign-key-indexes.md b/.agents/skills/supabase-postgres-best-practices/references/schema-foreign-key-indexes.md new file mode 100644 index 00000000..6c3d6ff6 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/schema-foreign-key-indexes.md @@ -0,0 +1,59 @@ +--- +title: Index Foreign Key Columns +impact: HIGH +impactDescription: 10-100x faster JOINs and CASCADE operations +tags: foreign-key, indexes, joins, schema +--- + +## Index Foreign Key Columns + +Postgres does not automatically index foreign key columns. Missing indexes cause slow JOINs and CASCADE operations. + +**Incorrect (unindexed foreign key):** + +```sql +create table orders ( + id bigint generated always as identity primary key, + customer_id bigint references customers(id) on delete cascade, + total numeric(10,2) +); + +-- No index on customer_id! +-- JOINs and ON DELETE CASCADE both require full table scan +select * from orders where customer_id = 123; -- Seq Scan +delete from customers where id = 123; -- Locks table, scans all orders +``` + +**Correct (indexed foreign key):** + +```sql +create table orders ( + id bigint generated always as identity primary key, + customer_id bigint references customers(id) on delete cascade, + total numeric(10,2) +); + +-- Always index the FK column +create index orders_customer_id_idx on orders (customer_id); + +-- Now JOINs and cascades are fast +select * from orders where customer_id = 123; -- Index Scan +delete from customers where id = 123; -- Uses index, fast cascade +``` + +Find missing FK indexes: + +```sql +select + conrelid::regclass as table_name, + a.attname as fk_column +from pg_constraint c +join pg_attribute a on a.attrelid = c.conrelid and a.attnum = any(c.conkey) +where c.contype = 'f' + and not exists ( + select 1 from pg_index i + where i.indrelid = c.conrelid and a.attnum = any(i.indkey) + ); +``` + +Reference: [Foreign Keys](https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-FK) diff --git a/.agents/skills/supabase-postgres-best-practices/references/schema-lowercase-identifiers.md b/.agents/skills/supabase-postgres-best-practices/references/schema-lowercase-identifiers.md new file mode 100644 index 00000000..f0072940 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/schema-lowercase-identifiers.md @@ -0,0 +1,55 @@ +--- +title: Use Lowercase Identifiers for Compatibility +impact: MEDIUM +impactDescription: Avoid case-sensitivity bugs with tools, ORMs, and AI assistants +tags: naming, identifiers, case-sensitivity, schema, conventions +--- + +## Use Lowercase Identifiers for Compatibility + +PostgreSQL folds unquoted identifiers to lowercase. Quoted mixed-case identifiers require quotes forever and cause issues with tools, ORMs, and AI assistants that may not recognize them. + +**Incorrect (mixed-case identifiers):** + +```sql +-- Quoted identifiers preserve case but require quotes everywhere +CREATE TABLE "Users" ( + "userId" bigint PRIMARY KEY, + "firstName" text, + "lastName" text +); + +-- Must always quote or queries fail +SELECT "firstName" FROM "Users" WHERE "userId" = 1; + +-- This fails - Users becomes users without quotes +SELECT firstName FROM Users; +-- ERROR: relation "users" does not exist +``` + +**Correct (lowercase snake_case):** + +```sql +-- Unquoted lowercase identifiers are portable and tool-friendly +CREATE TABLE users ( + user_id bigint PRIMARY KEY, + first_name text, + last_name text +); + +-- Works without quotes, recognized by all tools +SELECT first_name FROM users WHERE user_id = 1; +``` + +Common sources of mixed-case identifiers: + +```sql +-- ORMs often generate quoted camelCase - configure them to use snake_case +-- Migrations from other databases may preserve original casing +-- Some GUI tools quote identifiers by default - disable this + +-- If stuck with mixed-case, create views as a compatibility layer +CREATE VIEW users AS SELECT "userId" AS user_id, "firstName" AS first_name FROM "Users"; +``` + +Reference: [Identifiers and Key Words](https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS) diff --git a/.agents/skills/supabase-postgres-best-practices/references/schema-partitioning.md b/.agents/skills/supabase-postgres-best-practices/references/schema-partitioning.md new file mode 100644 index 00000000..13137a03 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/schema-partitioning.md @@ -0,0 +1,55 @@ +--- +title: Partition Large Tables for Better Performance +impact: MEDIUM-HIGH +impactDescription: 5-20x faster queries and maintenance on large tables +tags: partitioning, large-tables, time-series, performance +--- + +## Partition Large Tables for Better Performance + +Partitioning splits a large table into smaller pieces, improving query performance and maintenance operations. + +**Incorrect (single large table):** + +```sql +create table events ( + id bigint generated always as identity, + created_at timestamptz, + data jsonb +); + +-- 500M rows, queries scan everything +select * from events where created_at > '2024-01-01'; -- Slow +vacuum events; -- Takes hours, locks table +``` + +**Correct (partitioned by time range):** + +```sql +create table events ( + id bigint generated always as identity, + created_at timestamptz not null, + data jsonb +) partition by range (created_at); + +-- Create partitions for each month +create table events_2024_01 partition of events + for values from ('2024-01-01') to ('2024-02-01'); + +create table events_2024_02 partition of events + for values from ('2024-02-01') to ('2024-03-01'); + +-- Queries only scan relevant partitions +select * from events where created_at > '2024-01-15'; -- Only scans events_2024_01+ + +-- Drop old data instantly +drop table events_2023_01; -- Instant vs DELETE taking hours +``` + +When to partition: + +- Tables > 100M rows +- Time-series data with date-based queries +- Need to efficiently drop old data + +Reference: [Table Partitioning](https://www.postgresql.org/docs/current/ddl-partitioning.html) diff --git a/.agents/skills/supabase-postgres-best-practices/references/schema-primary-keys.md b/.agents/skills/supabase-postgres-best-practices/references/schema-primary-keys.md new file mode 100644 index 00000000..fb0fbb16 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/schema-primary-keys.md @@ -0,0 +1,61 @@ +--- +title: Select Optimal Primary Key Strategy +impact: HIGH +impactDescription: Better index locality, reduced fragmentation +tags: primary-key, identity, uuid, serial, schema +--- + +## Select Optimal Primary Key Strategy + +Primary key choice affects insert performance, index size, and replication +efficiency. + +**Incorrect (problematic PK choices):** + +```sql +-- identity is the SQL-standard approach +create table users ( + id serial primary key -- Works, but IDENTITY is recommended +); + +-- Random UUIDs (v4) cause index fragmentation +create table orders ( + id uuid default gen_random_uuid() primary key -- UUIDv4 = random = scattered inserts +); +``` + +**Correct (optimal PK strategies):** + +```sql +-- Use IDENTITY for sequential IDs (SQL-standard, best for most cases) +create table users ( + id bigint generated always as identity primary key +); + +-- For distributed systems needing UUIDs, use UUIDv7 (time-ordered) +-- Requires pg_uuidv7 extension: create extension pg_uuidv7; +create table orders ( + id uuid default uuid_generate_v7() primary key -- Time-ordered, no fragmentation +); + +-- Alternative: time-prefixed IDs for sortable, distributed IDs (no extension needed) +create table events ( + id text default concat( + to_char(now() at time zone 'utc', 'YYYYMMDDHH24MISSMS'), + gen_random_uuid()::text + ) primary key +); +``` + +Guidelines: + +- Single database: `bigint identity` (sequential, 8 bytes, SQL-standard) +- Distributed/exposed IDs: UUIDv7 (requires pg_uuidv7) or ULID (time-ordered, no + fragmentation) +- `serial` works but `identity` is SQL-standard and preferred for new + applications +- Avoid random UUIDs (v4) as primary keys on large tables (causes index + fragmentation) + +Reference: +[Identity Columns](https://www.postgresql.org/docs/current/sql-createtable.html#SQL-CREATETABLE-PARMS-GENERATED-IDENTITY) diff --git a/.agents/skills/supabase-postgres-best-practices/references/security-privileges.md b/.agents/skills/supabase-postgres-best-practices/references/security-privileges.md new file mode 100644 index 00000000..448ec345 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/security-privileges.md @@ -0,0 +1,54 @@ +--- +title: Apply Principle of Least Privilege +impact: MEDIUM +impactDescription: Reduced attack surface, better audit trail +tags: privileges, security, roles, permissions +--- + +## Apply Principle of Least Privilege + +Grant only the minimum permissions required. Never use superuser for application queries. + +**Incorrect (overly broad permissions):** + +```sql +-- Application uses superuser connection +-- Or grants ALL to application role +grant all privileges on all tables in schema public to app_user; +grant all privileges on all sequences in schema public to app_user; + +-- Any SQL injection becomes catastrophic +-- drop table users; cascades to everything +``` + +**Correct (minimal, specific grants):** + +```sql +-- Create role with no default privileges +create role app_readonly nologin; + +-- Grant only SELECT on specific tables +grant usage on schema public to app_readonly; +grant select on public.products, public.categories to app_readonly; + +-- Create role for writes with limited scope +create role app_writer nologin; +grant usage on schema public to app_writer; +grant select, insert, update on public.orders to app_writer; +grant usage on sequence orders_id_seq to app_writer; +-- No DELETE permission + +-- Login role inherits from these +create role app_user login password 'xxx'; +grant app_writer to app_user; +``` + +Revoke public defaults: + +```sql +-- Revoke default public access +revoke all on schema public from public; +revoke all on all tables in schema public from public; +``` + +Reference: [Roles and Privileges](https://supabase.com/blog/postgres-roles-and-privileges) diff --git a/.agents/skills/supabase-postgres-best-practices/references/security-rls-basics.md b/.agents/skills/supabase-postgres-best-practices/references/security-rls-basics.md new file mode 100644 index 00000000..c61e1a85 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/security-rls-basics.md @@ -0,0 +1,50 @@ +--- +title: Enable Row Level Security for Multi-Tenant Data +impact: CRITICAL +impactDescription: Database-enforced tenant isolation, prevent data leaks +tags: rls, row-level-security, multi-tenant, security +--- + +## Enable Row Level Security for Multi-Tenant Data + +Row Level Security (RLS) enforces data access at the database level, ensuring users only see their own data. + +**Incorrect (application-level filtering only):** + +```sql +-- Relying only on application to filter +select * from orders where user_id = $current_user_id; + +-- Bug or bypass means all data is exposed! +select * from orders; -- Returns ALL orders +``` + +**Correct (database-enforced RLS):** + +```sql +-- Enable RLS on the table +alter table orders enable row level security; + +-- Create policy for users to see only their orders +create policy orders_user_policy on orders + for all + using (user_id = current_setting('app.current_user_id')::bigint); + +-- Force RLS even for table owners +alter table orders force row level security; + +-- Set user context and query +set app.current_user_id = '123'; +select * from orders; -- Only returns orders for user 123 +``` + +Policy for authenticated role: + +```sql +create policy orders_user_policy on orders + for all + to authenticated + using (user_id = auth.uid()); +``` + +Reference: [Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security) diff --git a/.agents/skills/supabase-postgres-best-practices/references/security-rls-performance.md b/.agents/skills/supabase-postgres-best-practices/references/security-rls-performance.md new file mode 100644 index 00000000..c3c7c416 --- /dev/null +++ b/.agents/skills/supabase-postgres-best-practices/references/security-rls-performance.md @@ -0,0 +1,63 @@ +--- +title: Optimize RLS Policies for Performance +impact: HIGH +impactDescription: 5-10x faster RLS queries with proper patterns +tags: rls, performance, security, optimization +--- + +## Optimize RLS Policies for Performance + +Poorly written RLS policies can cause severe performance issues. Use subqueries and indexes strategically. + +**Incorrect (function called for every row):** + +```sql +create policy orders_policy on orders + using (auth.uid() = user_id); -- auth.uid() called per row! + +-- With 1M rows, auth.uid() is called 1M times +``` + +**Correct (wrap functions in SELECT):** + +```sql +create policy orders_policy on orders + using ((select auth.uid()) = user_id); -- Called once, cached + +-- 100x+ faster on large tables +``` + +Use security definer functions for complex checks: + +`SECURITY DEFINER` functions run with the creator's privileges and bypass RLS on any tables they touch — which is what makes them useful for internal lookups, but also what makes them dangerous if misused. Always include an explicit `auth.uid()` check inside the function body, keep them in a non-exposed schema, and revoke `EXECUTE` from any role that shouldn't call them directly. + +```sql +-- Create helper function in a private schema +create or replace function private.is_team_member(team_id bigint) +returns boolean +language sql +security definer +set search_path = '' +as $$ + select exists ( + select 1 from public.team_members + -- always check the calling user's identity inside the function + where team_id = $1 and user_id = (select auth.uid()) + ); +$$; + +-- Revoke direct execution from public roles +revoke execute on function private.is_team_member(bigint) from PUBLIC, anon, authenticated, service_role; + +-- Use in policy (indexed lookup, not per-row check) +create policy team_orders_policy on orders + using ((select private.is_team_member(team_id))); +``` + +Always add indexes on columns used in RLS policies: + +```sql +create index orders_user_id_idx on orders (user_id); +``` + +Reference: [RLS Performance](https://supabase.com/docs/guides/database/postgres/row-level-security#rls-performance-recommendations) diff --git a/.agents/skills/supabase/SKILL.md b/.agents/skills/supabase/SKILL.md new file mode 100644 index 00000000..a04e48a0 --- /dev/null +++ b/.agents/skills/supabase/SKILL.md @@ -0,0 +1,132 @@ +--- +name: supabase +description: "Use when doing ANY task involving Supabase. Triggers: Supabase products (Database, Auth, Edge Functions, Realtime, Storage, Vectors, Cron, Queues); client libraries and SSR integrations (supabase-js, @supabase/ssr) in Next.js, React, SvelteKit, Astro, Remix; auth issues (login, logout, sessions, JWT, cookies, getSession, getUser, getClaims, RLS); Supabase CLI or MCP server; schema changes, migrations, security audits, Postgres extensions (pg_graphql, pg_cron, pg_vector)." +metadata: + author: supabase + version: "0.1.2" +--- + +# Supabase + +## Core Principles + +**1. Supabase changes frequently — verify against changelog and current docs before implementing.** +Do not rely on training data for Supabase features. Function signatures, config.toml settings, and API conventions change between versions. + +First, fetch `https://supabase.com/changelog.md` (a lightweight summary index — not a heavy pull), scan for `breaking-change` tags relevant to your task, and follow the linked page for any that apply. Then look up the relevant topic using the documentation access methods below. + +**2. Verify your work.** +After implementing any fix, run a test query to confirm the change works. A fix without verification is incomplete. + +**3. Recover from errors, don't loop.** +If an approach fails after 2-3 attempts, stop and reconsider. Try a different method, check documentation, inspect the error more carefully, and review relevant logs when available. Supabase issues are not always solved by retrying the same command, and the answer is not always in the logs, but logs are often worth checking before proceeding. + +**4. Exposing tables to the Data API:** Depending on the user's [Data API settings](https://supabase.com/dashboard/project//integrations/data_api/settings), newly created tables may not be automatically exposed via the Data (REST) API. If this is the case, `anon` and `authenticated` roles will need to be explicitly granted access. + +> Note that this is separate from RLS, which controls which _rows_ are visible once a table is accessible, not whether the table is accessible at all. + +When a user reports a SQL-created table is unexpectedly inaccessible, check their Data API settings and whether the roles have been granted access via explicit `GRANT` SQL. When granting public (`anon`/`authenticated`) access, always enable RLS too. See [Exposing a Table to the Data API](https://supabase.com/docs/guides/api/securing-your-api.md) for the full setup workflow. + +**5. RLS in exposed schemas.** +Enable RLS on every table in any exposed schema, which includes `public` by default. This is critical in Supabase because tables in exposed schemas can be reachable through the Data API when the `anon`/`authenticated` roles have access (see [Exposing a Table to the Data API](https://supabase.com/docs/guides/api/securing-your-api.md)). For private schemas, prefer RLS as defense in depth. After enabling RLS, create policies that match the actual access model rather than defaulting every table to the same `auth.uid()` pattern. + +**6. Security checklist.** +When working on any Supabase task that touches auth, RLS, views, storage, or user data, run through this checklist. These are Supabase-specific security traps that silently create vulnerabilities: + +- **Auth and session security** + - **Never use `user_metadata` claims in JWT-based authorization decisions.** In Supabase, `raw_user_meta_data` is user-editable and can appear in `auth.jwt()`, so it is unsafe for RLS policies or any other authorization logic. Store authorization data in `raw_app_meta_data` / `app_metadata` instead. + - **Deleting a user does not invalidate existing access tokens.** Sign out or revoke sessions first, keep JWT expiry short for sensitive apps, and for strict guarantees validate `session_id` against `auth.sessions` on sensitive operations. + - **If you use `app_metadata` or `auth.jwt()` for authorization, remember JWT claims are not always fresh until the user's token is refreshed.** + +- **API key and client exposure** + - **Never expose the `service_role` or secret key in public clients.** Prefer publishable keys for frontend code. Legacy `anon` keys are only for compatibility. In Next.js, any `NEXT_PUBLIC_` env var is sent to the browser. + +- **RLS, views, and privileged database code** + - **Views bypass RLS by default.** In Postgres 15 and above, use `CREATE VIEW ... WITH (security_invoker = true)`. In older versions of Postgres, protect your views by revoking access from the `anon` and `authenticated` roles, or by putting them in an unexposed schema. + - **UPDATE requires a SELECT policy.** In Postgres RLS, an UPDATE needs to first SELECT the row. Without a SELECT policy, updates silently return 0 rows — no error, just no change. + - **`auth.role()` is deprecated — use the `TO` clause instead.** Supabase has deprecated `auth.role()` in favour of specifying the target role directly on the policy with `TO authenticated` or `TO anon`. Beyond deprecation, `auth.role() = 'authenticated'` breaks silently when anonymous sign-ins are enabled, because anonymous users carry the `authenticated` Postgres role and pass the check regardless of whether the user is genuinely signed in. + ```sql + -- Deprecated (do not use) + create policy "example" on table_name for select + using ( auth.role() = 'authenticated' ); + ``` + - **`TO authenticated` alone is authentication without authorization (BOLA / IDOR).** Using `TO authenticated` only checks the role — it does not restrict which rows a user can access. The correct pattern combines `TO authenticated` with an ownership predicate in `USING`: + ```sql + create policy "example" on table_name for select + to authenticated + using ( (select auth.uid()) = user_id ); + ``` + - **UPDATE policies require both `USING` and `WITH CHECK`.** Without `WITH CHECK`, a user can reassign a row's `user_id` to another user: + ```sql + create policy "example" on table_name for update + to authenticated + using ( (select auth.uid()) = user_id ) + with check ( (select auth.uid()) = user_id ); + ``` + - **`SECURITY DEFINER` functions bypass RLS.** A `SECURITY DEFINER` function runs with its creator's privileges — typically a role with `bypassrls` (e.g., `postgres`). Never add `SECURITY DEFINER` to resolve a permission error; it silently removes access control without fixing the underlying cause. Prefer `SECURITY INVOKER`. + - **`SECURITY DEFINER` functions in `public` are callable by all roles.** Postgres grants `EXECUTE` to `PUBLIC` by default for every new function, so any `SECURITY DEFINER` function in `public` is a public API endpoint callable by `anon` and `authenticated` (which inherit from `PUBLIC`) without any additional grant. When `SECURITY DEFINER` is genuinely needed (e.g., bypassing RLS on an internal lookup table), keep the function in a non-exposed schema, always include an `auth.uid()` check in the function body, and run `supabase db advisors` after making changes. + +- **Storage access control** + - **Storage upsert requires INSERT + SELECT + UPDATE.** Granting only INSERT allows new uploads but file replacement (upsert) silently fails. You need all three. + +For any security concern not covered above, fetch the Supabase product security index: `https://supabase.com/docs/guides/security/product-security.md` + +## Supabase CLI + +Always discover commands via `--help` — never guess. The CLI structure changes between versions. + +```bash +supabase --help # All top-level commands +supabase --help # Subcommands (e.g., supabase db --help) +supabase --help # Flags for a specific command +``` + +**Supabase CLI Known gotchas:** + +- `supabase db query` requires **CLI v2.79.0+** → use MCP `execute_sql` or `psql` as fallback +- `supabase db advisors` requires **CLI v2.81.3+** → use MCP `get_advisors` as fallback +- When you need a new migration SQL file, **always** create it with `supabase migration new ` first. Never invent a migration filename or rely on memory for the expected format. + +**Version check and upgrade:** Run `supabase --version` to check. For CLI changelogs and version-specific features, consult the [CLI documentation](https://supabase.com/docs/reference/cli/introduction) or [GitHub releases](https://github.com/supabase/cli/releases). + +## Supabase MCP Server + +For setup instructions, server URL, and configuration, see the [MCP setup guide](https://supabase.com/docs/guides/getting-started/mcp). + +**Troubleshooting connection issues** — follow these steps in order: + +1. **Check if the server is reachable:** + `curl -so /dev/null -w "%{http_code}" https://mcp.supabase.com/mcp` + A `401` is expected (no token) and means the server is up. Timeout or "connection refused" means it may be down. + +2. **Check `.mcp.json` configuration:** + Verify the project root has a valid `.mcp.json` with the correct server URL. If missing, create one pointing to `https://mcp.supabase.com/mcp`. + +3. **Authenticate the MCP server:** + If the server is reachable and `.mcp.json` is correct but tools aren't visible, the user needs to authenticate. The Supabase MCP server uses OAuth 2.1 — tell the user to trigger the auth flow in their agent, complete it in the browser, and reload the session. + +## Supabase Documentation + +Before implementing any Supabase feature, find the relevant documentation. Use these methods in priority order: + +1. **MCP `search_docs` tool** (preferred — returns relevant snippets directly) +2. **Fetch docs pages as markdown** — any docs page can be fetched by appending `.md` to the URL path. +3. **Web search** for Supabase-specific topics when you don't know which page to look at. + +## Making and Committing Schema Changes + +**To make schema changes, use `execute_sql` (MCP) or `supabase db query` (CLI).** These run SQL directly on the database without creating migration history entries, so you can iterate freely and generate a clean migration when ready. + +Do NOT use `apply_migration` to change a local database schema — it writes a migration history entry on every call, which means you can't iterate, and `supabase db diff` / `supabase db pull` will produce empty or conflicting diffs. If you use it, you'll be stuck with whatever SQL you passed on the first try. + +**When ready to commit** your changes to a migration file: + +1. **Run advisors** → `supabase db advisors` (CLI v2.81.3+) or MCP `get_advisors`. Fix any issues. +2. **Review the Security Checklist above** if your changes involve views, functions, triggers, or storage. +3. **Generate the migration** → `supabase db pull --local --yes` +4. **Verify** → `supabase migration list --local` + +## Reference Guides + +- **Skill Feedback** → [references/skill-feedback.md](references/skill-feedback.md) + **MUST read when** the user reports that this skill gave incorrect guidance or is missing information. diff --git a/.agents/skills/supabase/assets/feedback-issue-template.md b/.agents/skills/supabase/assets/feedback-issue-template.md new file mode 100644 index 00000000..e8108253 --- /dev/null +++ b/.agents/skills/supabase/assets/feedback-issue-template.md @@ -0,0 +1,17 @@ +## What happened + +**Task:** + +**Skill said:** + +**Expected:** + +## Source + +**File:** + +**Section:** + +## Fix suggestion + + diff --git a/.agents/skills/supabase/references/skill-feedback.md b/.agents/skills/supabase/references/skill-feedback.md new file mode 100644 index 00000000..9c047d5a --- /dev/null +++ b/.agents/skills/supabase/references/skill-feedback.md @@ -0,0 +1,17 @@ +# Skill Feedback + +Use this when the user reports that the skill gave incorrect guidance, is missing information, or could be improved. This is about the skill (agent instructions), not about Supabase the product. + +## Steps + +1. **Ask permission** — Ask the user if they'd like to submit feedback to the skill maintainers. If they decline, move on. + +2. **Draft the issue** — Use the template at [assets/feedback-issue-template.md](../assets/feedback-issue-template.md) to structure the feedback. Fill in the fields based on the conversation. Always identify which specific reference file and section caused the problem. + +3. **Submit** — Create a GitHub Issue on the `supabase/agent-skills` repository using the draft as the issue body. The title must follow this format: `user-feedback: `. + +4. **Share the result** — Share the issue URL with the user after submission. If submission fails, give the user this link to create the issue manually: + +``` +https://github.com/supabase/agent-skills/issues/new +``` diff --git a/.claude/skills/supabase b/.claude/skills/supabase new file mode 120000 index 00000000..14e4b541 --- /dev/null +++ b/.claude/skills/supabase @@ -0,0 +1 @@ +../../.agents/skills/supabase \ No newline at end of file diff --git a/.claude/skills/supabase-postgres-best-practices b/.claude/skills/supabase-postgres-best-practices new file mode 120000 index 00000000..4990773c --- /dev/null +++ b/.claude/skills/supabase-postgres-best-practices @@ -0,0 +1 @@ +../../.agents/skills/supabase-postgres-best-practices \ No newline at end of file diff --git a/skills-lock.json b/skills-lock.json new file mode 100644 index 00000000..c98a463b --- /dev/null +++ b/skills-lock.json @@ -0,0 +1,17 @@ +{ + "version": 1, + "skills": { + "supabase": { + "source": "supabase/agent-skills", + "sourceType": "github", + "skillPath": "skills/supabase/SKILL.md", + "computedHash": "1bb189e255c0e91161f14c618dce0eccf68174ceb963664cef7761b2f90cb466" + }, + "supabase-postgres-best-practices": { + "source": "supabase/agent-skills", + "sourceType": "github", + "skillPath": "skills/supabase-postgres-best-practices/SKILL.md", + "computedHash": "292c93e5a86e2429204bc37abe26b3c9023c4760eb02418462887f2082f118ce" + } + } +} From f4c9fbf76e735d0f3f84cb7ecad03eb11b118486 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 20 May 2026 08:09:52 +0000 Subject: [PATCH 11/18] fix(scripts): drop slug-uniqueness handling from sync, fix db url docs The artists slug-uniqueness constraint is owned by a separate PR and is not present in this repo's migrations, so the sync script no longer drops/dedupes/re-adds artists_slug_unique. Also clarify that the DB URL env vars accept any valid postgres connection URL. https://claude.ai/code/session_01L4WM1ni4NX1mpWUdGkVodk --- scripts/recreate-staging.sh | 4 ++-- scripts/sync-from-prod.sh | 22 ---------------------- 2 files changed, 2 insertions(+), 24 deletions(-) diff --git a/scripts/recreate-staging.sh b/scripts/recreate-staging.sh index f7a3c18d..2c5d3e49 100755 --- a/scripts/recreate-staging.sh +++ b/scripts/recreate-staging.sh @@ -13,8 +13,8 @@ # Required env vars (put them in scripts/.env.sync, which is gitignored): # STAGING_PROJECT_REF Supabase project ref for staging # STAGING_DB_PASSWORD Staging DB password (for `supabase link`) -# STAGING_DB_URL Direct postgres URL for staging -# PROD_DB_URL Direct postgres URL for prod +# STAGING_DB_URL Postgres connection URL for staging +# PROD_DB_URL Postgres connection URL for prod # STAGING_URL Staging project URL (https://.supabase.co) # STAGING_SERVICE_ROLE_KEY Staging service role key (for the admin Auth API) # diff --git a/scripts/sync-from-prod.sh b/scripts/sync-from-prod.sh index b27c5036..f4a6b15f 100755 --- a/scripts/sync-from-prod.sh +++ b/scripts/sync-from-prod.sh @@ -146,13 +146,6 @@ BEGIN END $$; SQL -echo "Relaxing artists.slug uniqueness for restore…" -# Prod may pre-date the slug-dedupe migration, so its data can contain -# duplicate slugs that would violate the target's constraint. Drop it now -# and re-add it (with a dedupe pass) after the restore. -psql "$TARGET_URL" -v ON_ERROR_STOP=1 \ - -c "ALTER TABLE public.artists DROP CONSTRAINT IF EXISTS artists_slug_unique;" - echo "Restoring dump into target…" psql "$TARGET_URL" -v ON_ERROR_STOP=1 < 1 -); -ALTER TABLE public.artists ADD CONSTRAINT artists_slug_unique UNIQUE (slug); -SQL - echo "Running anonymizer on public schema…" psql "$TARGET_URL" -v ON_ERROR_STOP=1 -f "$SCRIPT_DIR/anonymize.sql" From 0dcdb9594477d0f6b3eccb0f3fd21e4ca10fdd8f Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 20 May 2026 08:17:02 +0000 Subject: [PATCH 12/18] chore: neutralize legacy artist seed migrations 20250620121419 and 20250620121752 inserted a hardcoded artist roster and relied on a profiles row (for artists.added_by) created by the already -neutralized 20250620080928 seed migration. With that profile gone they fail with a not-null violation on a fresh DB. Neutralized to no-ops, consistent with the seed-data-belongs-in-seed.sql decision. https://claude.ai/code/session_01L4WM1ni4NX1mpWUdGkVodk --- .../20250620121419_update_artists_data.sql | 259 +------------- .../migrations/20250620121752_migration.sql | 338 +----------------- 2 files changed, 16 insertions(+), 581 deletions(-) diff --git a/supabase/migrations/20250620121419_update_artists_data.sql b/supabase/migrations/20250620121419_update_artists_data.sql index 93562b4a..8bb657db 100644 --- a/supabase/migrations/20250620121419_update_artists_data.sql +++ b/supabase/migrations/20250620121419_update_artists_data.sql @@ -1,251 +1,8 @@ - --- First, let's update existing artists with their stage and estimated date information -UPDATE public.artists SET - stage = 'Alchemy Circle', - estimated_date = '2024-07-19' -WHERE name = 'FREEDOM FIGHTERS'; - -UPDATE public.artists SET - stage = 'Alchemy Circle', - estimated_date = '2024-07-19' -WHERE name = 'JOHN 00 FLEMING'; - -UPDATE public.artists SET - stage = 'Dance Temple', - estimated_date = '2024-07-19' -WHERE name = 'TRISTAN'; - -UPDATE public.artists SET - stage = 'The Gardens', - estimated_date = '2024-07-19' -WHERE name = 'FRIDA DARKO'; - -UPDATE public.artists SET - stage = 'The Gardens', - estimated_date = '2024-07-19' -WHERE name = 'KALYA SCINTILLA'; - -UPDATE public.artists SET - stage = 'Dance Temple', - estimated_date = '2024-07-20' -WHERE name = 'TSUYOSHI SUZUKI'; - -UPDATE public.artists SET - stage = 'Dance Temple', - estimated_date = '2024-07-21', - spotify_url = 'https://open.spotify.com/artist/7bSyjB4y9NAhoUDrZTpYt4', - soundcloud_url = 'https://soundcloud.com/schatsi' -WHERE name = 'ACE VENTURA'; - -UPDATE public.artists SET - stage = 'Alchemy Circle', - estimated_date = '2024-07-21' -WHERE name = 'MERKABA'; - -UPDATE public.artists SET - stage = 'Alchemy Circle', - estimated_date = '2024-07-22' -WHERE name = 'ATIA'; - -UPDATE public.artists SET - stage = 'Alchemy Circle', - estimated_date = '2024-07-23' -WHERE name = 'RITMO'; - -UPDATE public.artists SET - stage = 'Dance Temple', - estimated_date = NULL, - spotify_url = 'https://open.spotify.com/artist/3dUltShd2gJQc98Kc7Syit', - soundcloud_url = 'https://soundcloud.com/astrix-official' -WHERE name = 'ASTRIX'; - -UPDATE public.artists SET - stage = 'Dance Temple', - estimated_date = NULL -WHERE name = 'ATMOS'; - -UPDATE public.artists SET - stage = 'Dance Temple', - estimated_date = NULL -WHERE name = 'PROMETHEUS'; - -UPDATE public.artists SET - stage = 'Alchemy Circle', - estimated_date = NULL -WHERE name = 'AKARI SYSTEM'; - -UPDATE public.artists SET - stage = 'Alchemy Circle', - estimated_date = NULL -WHERE name = 'BOUNDLESS'; - -UPDATE public.artists SET - stage = 'Alchemy Circle', - estimated_date = NULL -WHERE name = 'CARBON'; - -UPDATE public.artists SET - stage = 'Alchemy Circle', - estimated_date = NULL -WHERE name = 'KLIMENT'; - -UPDATE public.artists SET - stage = 'Alchemy Circle', - estimated_date = NULL -WHERE name = 'KRUMELUR'; - -UPDATE public.artists SET - stage = 'Alchemy Circle', - estimated_date = NULL -WHERE name = 'MILES FROM MARS'; - -UPDATE public.artists SET - stage = 'Alchemy Circle', - estimated_date = NULL -WHERE name = 'NEUROLABZ'; - -UPDATE public.artists SET - stage = 'Alchemy Circle', - estimated_date = NULL, - spotify_url = 'https://open.spotify.com/artist/3AhwIUus3pIaA3CvYBEtpy', - soundcloud_url = 'https://soundcloud.com/RICHIEHAWTIN' -WHERE name = 'RICHIE HAWTIN'; - --- Now let's insert all the new artists from the table, using an existing user ID -DO $$ -DECLARE - psytrance_id UUID; - techno_id UUID; - trance_id UUID; - tribal_id UUID; - downtempo_id UUID; - progressive_id UUID; - existing_user_id UUID; -BEGIN - -- Get genre IDs - SELECT id INTO psytrance_id FROM public.music_genres WHERE name = 'Psytrance'; - SELECT id INTO techno_id FROM public.music_genres WHERE name = 'Techno'; - SELECT id INTO trance_id FROM public.music_genres WHERE name = 'Trance'; - SELECT id INTO tribal_id FROM public.music_genres WHERE name = 'Tribal/bass'; -- Fix genre name - SELECT id INTO downtempo_id FROM public.music_genres WHERE name = 'Downtempo'; - SELECT id INTO progressive_id FROM public.music_genres WHERE name = 'Progressive'; - - -- Get an existing user ID from the profiles table - SELECT id INTO existing_user_id FROM public.profiles LIMIT 1; - - -- Insert new artists only if they don't already exist - -- July 18 - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'CELLI/EARTHLING') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('CELLI/EARTHLING', 'Dance Temple', '2024-07-18', psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'AARDVARKK') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('AARDVARKK', 'Dance Temple', '2024-07-18', psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'KAUFMANN') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('KAUFMANN', 'Alchemy Circle', '2024-07-18', techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'RUGRATS') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('RUGRATS', 'Dance Temple', '2024-07-18', psytrance_id, existing_user_id); - END IF; - - -- July 19 - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'MENOG') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('MENOG', 'Dance Temple', '2024-07-19', psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'DJANTRIX') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('DJANTRIX', 'Dance Temple', '2024-07-19', psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'DJ NUKY') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('DJ NUKY', 'Dance Temple', '2024-07-19', psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'GIUSEPPE') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('GIUSEPPE', 'Dance Temple', '2024-07-19', psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'AiÊ (Edgar Valente & LuizG)') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('AiÊ (Edgar Valente & LuizG)', 'Sacred Fire', '2024-07-19', tribal_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'HERRHAUSEN & TREINDL') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('HERRHAUSEN & TREINDL', 'The Gardens', '2024-07-19', downtempo_id, existing_user_id); - END IF; - - -- July 20 - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ARJUNA') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ARJUNA', 'Dance Temple', '2024-07-20', psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = '8TERNAL BEINGS') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('8TERNAL BEINGS', 'Dance Temple', '2024-07-20', psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'BALANCÉ') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('BALANCÉ', 'TBD', '2024-07-20', progressive_id, existing_user_id); - END IF; - - -- July 21 - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ALIEN ART') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ALIEN ART', 'Alchemy Circle', '2024-07-21', trance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'YIN YIN BAND') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('YIN YIN BAND', 'Sacred Fire', '2024-07-21', tribal_id, existing_user_id); - END IF; - - -- July 22 - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'KONEBU') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('KONEBU', 'Dance Temple', '2024-07-22', psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'NASHA') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('NASHA', 'Dance Temple', '2024-07-22', psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'CAPTAIN HOOK') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by, spotify_url, soundcloud_url) VALUES ('CAPTAIN HOOK', 'Alchemy Circle', '2024-07-22', trance_id, existing_user_id, 'https://open.spotify.com/artist/5xnZNDl118VvPTvthujxpx', 'https://soundcloud.com/captain-hook'); - END IF; - - -- July 23 - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ACT ONE') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ACT ONE', 'Dance Temple', '2024-07-23', psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'AVALON') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('AVALON', 'Dance Temple', '2024-07-23', psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'FERNANDA PISTELLI') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('FERNANDA PISTELLI', 'Alchemy Circle', '2024-07-23', trance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'UNCHARTED TERRITORY') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('UNCHARTED TERRITORY', 'Alchemy Circle', '2024-07-23', trance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'OUTSIDERS') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('OUTSIDERS', 'Dance Temple', '2024-07-23', psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ZEN BABOOM') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ZEN BABOOM', 'The Gardens', '2024-07-23', downtempo_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'AVAN7') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('AVAN7', 'Dance Temple', '2024-07-23', psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ALTRUISM') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ALTRUISM', 'Dance Temple', '2024-07-23', psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'STARLAB') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('STARLAB', 'Dance Temple', '2024-07-23', psytrance_id, existing_user_id); - END IF; - -END $$; +-- Neutralized: this migration originally seeded a hardcoded artist roster and +-- depended on a `profiles` row (for `artists.added_by`) created by the +-- now-neutralized 20250620080928_seed_artists_data.sql. Seed data does not +-- belong in migrations -- supabase/seed.sql is the supported mechanism and +-- staging/prod-like data comes from scripts/sync-from-prod.sh. +-- +-- The body is kept as a no-op so the migration history stays intact on +-- environments where it already ran. diff --git a/supabase/migrations/20250620121752_migration.sql b/supabase/migrations/20250620121752_migration.sql index f36171f9..8bb657db 100644 --- a/supabase/migrations/20250620121752_migration.sql +++ b/supabase/migrations/20250620121752_migration.sql @@ -1,330 +1,8 @@ - --- Continue inserting the remaining TBD artists from the table -DO $$ -DECLARE - psytrance_id UUID; - techno_id UUID; - trance_id UUID; - tribal_id UUID; - downtempo_id UUID; - progressive_id UUID; - existing_user_id UUID; -BEGIN - -- Get genre IDs - SELECT id INTO psytrance_id FROM public.music_genres WHERE name = 'Psytrance'; - SELECT id INTO techno_id FROM public.music_genres WHERE name = 'Techno'; - SELECT id INTO trance_id FROM public.music_genres WHERE name = 'Trance'; - SELECT id INTO tribal_id FROM public.music_genres WHERE name = 'Tribal/bass'; - SELECT id INTO downtempo_id FROM public.music_genres WHERE name = 'Downtempo'; - SELECT id INTO progressive_id FROM public.music_genres WHERE name = 'Progressive'; - - -- Get an existing user ID from the profiles table - SELECT id INTO existing_user_id FROM public.profiles LIMIT 1; - - -- Insert remaining TBD Dance Temple artists - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ARCHAIC') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ARCHAIC', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ARCHE GOAH') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ARCHE GOAH', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'AURAL EYE') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('AURAL EYE', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'BOOGIE KNIGHT') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('BOOGIE KNIGHT', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'CELESTIAL INTELLIGENCE') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('CELESTIAL INTELLIGENCE', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'DIGITAL HIPPIE') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('DIGITAL HIPPIE', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'DJ MAILISE') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('DJ MAILISE', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'DRIP DROP') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('DRIP DROP', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'E-CLIP') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('E-CLIP', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'EMOK') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('EMOK', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ETNICA & PLEIADIANS') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ETNICA & PLEIADIANS', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'EVP') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('EVP', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'FAREBI JALEBI') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('FAREBI JALEBI', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'FIDDLE FADDLE') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('FIDDLE FADDLE', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'FISHEYE') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('FISHEYE', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'FUTUREMOON') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('FUTUREMOON', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'GLOBAL ILLUMINATION') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('GLOBAL ILLUMINATION', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'GOVINDA') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('GOVINDA', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'IGOR SWAMP') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('IGOR SWAMP', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ITAL') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ITAL', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'JAHBO') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('JAHBO', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'MAGIK') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('MAGIK', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'METAPHYZ') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('METAPHYZ', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'NINESENSE') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('NINESENSE', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'NITIN') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('NITIN', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ORESTIS') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ORESTIS', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'SABEDORIA') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('SABEDORIA', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'SATOR AREPO') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('SATOR AREPO', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'SECTIO AUREA') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('SECTIO AUREA', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'SHANTI V DEEDRAH') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('SHANTI V DEEDRAH', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'SPECTRA SONICS') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('SPECTRA SONICS', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'SPINAL FUSION') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('SPINAL FUSION', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'TAOLIND') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('TAOLIND', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'TAS') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('TAS', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'TECHYON') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('TECHYON', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'THIRD EYE OF MONKEY') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('THIRD EYE OF MONKEY', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ULVAE') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ULVAE', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'UMBER SONUS') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('UMBER SONUS', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'YABBA DABBA') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('YABBA DABBA', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ZEN MECHANICS') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ZEN MECHANICS', 'Dance Temple', NULL, psytrance_id, existing_user_id); - END IF; - - -- Insert remaining TBD Alchemy Circle artists - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'AIRI') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('AIRI', 'Alchemy Circle', NULL, trance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ALEX STEIN & VICTOR RUIZ') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ALEX STEIN & VICTOR RUIZ', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ALEX TOLSTEY') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ALEX TOLSTEY', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ANAH') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ANAH', 'Alchemy Circle', NULL, trance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ANAïS-LIN') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ANAïS-LIN', 'Alchemy Circle', NULL, trance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ANDRÉ CASCAIS') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ANDRÉ CASCAIS', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ANNA') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ANNA', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'BANEL') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('BANEL', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'BEATBOMBERS SPECIAL PSYCHEDELIC TURNTABLISM SHOW') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('BEATBOMBERS SPECIAL PSYCHEDELIC TURNTABLISM SHOW', 'Alchemy Circle', NULL, trance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'COLECTIVE WAREHOUSE') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('COLECTIVE WAREHOUSE', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'CHAMPIROLLS') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('CHAMPIROLLS', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'DATAGRAMA') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('DATAGRAMA', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'DELTA PROCESS') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('DELTA PROCESS', 'Alchemy Circle', NULL, trance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'D-NOX & BECKERS') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('D-NOX & BECKERS', 'Alchemy Circle', NULL, trance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'DJ MARIA') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('DJ MARIA', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'DJ MARKY') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('DJ MARKY', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ELE LUZ') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ELE LUZ', 'Alchemy Circle', NULL, trance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ERROR 43') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ERROR 43', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'FRESHKITOS') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('FRESHKITOS', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'IDA ENGBERG') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('IDA ENGBERG', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'JAMES MONRO') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('JAMES MONRO', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'JULIUS HORSTHUIS') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('JULIUS HORSTHUIS', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'KARIM ALKHAYAT') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('KARIM ALKHAYAT', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'KOKESHI') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('KOKESHI', 'Alchemy Circle', NULL, trance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'MARYCROFT') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('MARYCROFT', 'Alchemy Circle', NULL, trance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'METHODIC SPIN') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('METHODIC SPIN', 'Alchemy Circle', NULL, trance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'MIDINOIZE') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('MIDINOIZE', 'Alchemy Circle', NULL, trance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'NEGRÃO') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('NEGRÃO', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'PATRICE BÄUMEL') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('PATRICE BÄUMEL', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'RØDHÅD') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('RØDHÅD', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'RELIQUARIUM') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('RELIQUARIUM', 'Alchemy Circle', NULL, trance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'SOURONE') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('SOURONE', 'Alchemy Circle', NULL, trance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'VAL VASHAR') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('VAL VASHAR', 'Alchemy Circle', NULL, trance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'VJ DATASET') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('VJ DATASET', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'YUSS') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('YUSS', 'Alchemy Circle', NULL, trance_id, existing_user_id); - END IF; - - IF NOT EXISTS (SELECT 1 FROM public.artists WHERE name = 'ZIGMON') THEN - INSERT INTO public.artists (name, stage, estimated_date, genre_id, added_by) VALUES ('ZIGMON', 'Alchemy Circle', NULL, techno_id, existing_user_id); - END IF; - -END $$; +-- Neutralized: this migration originally seeded a hardcoded artist roster and +-- depended on a `profiles` row (for `artists.added_by`) created by the +-- now-neutralized 20250620080928_seed_artists_data.sql. Seed data does not +-- belong in migrations -- supabase/seed.sql is the supported mechanism and +-- staging/prod-like data comes from scripts/sync-from-prod.sh. +-- +-- The body is kept as a no-op so the migration history stays intact on +-- environments where it already ran. From c5013380a2ae5945d5d20cccd342ba084f93aa3a Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 20 May 2026 09:10:00 +0000 Subject: [PATCH 13/18] fix(scripts): pass admin email as a psql variable Interpolating ADMIN_EMAIL into the SQL string broke on emails containing a single quote. Pass it via psql -v and quote with :'email' instead. https://claude.ai/code/session_01L4WM1ni4NX1mpWUdGkVodk --- scripts/recreate-staging.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/recreate-staging.sh b/scripts/recreate-staging.sh index 2c5d3e49..722a9b91 100755 --- a/scripts/recreate-staging.sh +++ b/scripts/recreate-staging.sh @@ -122,8 +122,8 @@ if [[ -z "$USER_ID" ]]; then fi echo "→ Promoting '$ADMIN_EMAIL' to super_admin…" -psql "$STAGING_DB_URL" -v ON_ERROR_STOP=1 \ - -c "SELECT public.bootstrap_super_admin('$ADMIN_EMAIL');" +psql "$STAGING_DB_URL" -v ON_ERROR_STOP=1 -v email="$ADMIN_EMAIL" \ + -c "SELECT public.bootstrap_super_admin(:'email');" cat < Date: Wed, 20 May 2026 10:32:43 +0000 Subject: [PATCH 14/18] refactor(queries): build mutation payloads from an explicit field allowlist Set/artist create and update mutations spread the caller's object and stripped derived join fields (stage_name, soundcloud_followers). That let any newly added field flow straight to the DB. Build the payload from an explicit list of writable columns instead, so new fields are opt-in rather than forwarded by default. https://claude.ai/code/session_01L4WM1ni4NX1mpWUdGkVodk --- src/hooks/queries/artists/useUpdateArtist.ts | 45 ++++++++++++++++---- src/hooks/queries/sets/useCreateSet.ts | 21 ++++++--- src/hooks/queries/sets/useUpdateSet.ts | 32 +++++++++++--- 3 files changed, 79 insertions(+), 19 deletions(-) diff --git a/src/hooks/queries/artists/useUpdateArtist.ts b/src/hooks/queries/artists/useUpdateArtist.ts index 7dd4b6cb..9d27395b 100644 --- a/src/hooks/queries/artists/useUpdateArtist.ts +++ b/src/hooks/queries/artists/useUpdateArtist.ts @@ -1,9 +1,12 @@ import { useMutation, useQueryClient } from "@tanstack/react-query"; import { useToast } from "@/hooks/use-toast"; import { supabase } from "@/integrations/supabase/client"; +import type { Database } from "@/integrations/supabase/types"; import { generateSlug } from "@/lib/slug"; import { Artist, artistsKeys } from "./useArtists"; +type ArtistUpdate = Database["public"]["Tables"]["artists"]["Update"]; + export type UpdateArtistUpdates = Partial< Omit & { genre_ids: string[] } >; @@ -14,20 +17,46 @@ async function updateArtist(variables: { updates: UpdateArtistUpdates; }): Promise> { const { id, updates } = variables; - const { genre_ids, soundcloud_followers: _sf, ...rest } = updates; + const { genre_ids } = updates; - // If name is being updated, regenerate slug - const updateData = { ...rest }; - if (updates.name) { + const updateData: ArtistUpdate = { + updated_at: new Date().toISOString(), + }; + if (updates.name !== undefined) { + updateData.name = updates.name; updateData.slug = generateSlug(updates.name); } + if (updates.description !== undefined) { + updateData.description = updates.description; + } + if (updates.estimated_date !== undefined) { + updateData.estimated_date = updates.estimated_date; + } + if (updates.image_url !== undefined) { + updateData.image_url = updates.image_url; + } + if (updates.soundcloud_url !== undefined) { + updateData.soundcloud_url = updates.soundcloud_url; + } + if (updates.spotify_url !== undefined) { + updateData.spotify_url = updates.spotify_url; + } + if (updates.stage !== undefined) { + updateData.stage = updates.stage; + } + if (updates.time_start !== undefined) { + updateData.time_start = updates.time_start; + } + if (updates.time_end !== undefined) { + updateData.time_end = updates.time_end; + } + if (updates.archived !== undefined) { + updateData.archived = updates.archived; + } const { data, error } = await supabase .from("artists") - .update({ - ...updateData, - updated_at: new Date().toISOString(), - }) + .update(updateData) .eq("id", id) .select( ` diff --git a/src/hooks/queries/sets/useCreateSet.ts b/src/hooks/queries/sets/useCreateSet.ts index e4f8004c..0e245b2c 100644 --- a/src/hooks/queries/sets/useCreateSet.ts +++ b/src/hooks/queries/sets/useCreateSet.ts @@ -1,9 +1,12 @@ import { useMutation, useQueryClient } from "@tanstack/react-query"; import { useToast } from "@/hooks/use-toast"; import { supabase } from "@/integrations/supabase/client"; +import type { Database } from "@/integrations/supabase/types"; import { generateSlug } from "@/lib/slug"; import { FestivalSet, setsKeys } from "./useSets"; +type SetInsert = Database["public"]["Tables"]["sets"]["Insert"]; + // Mutation function async function createSet( setData: Omit< @@ -18,16 +21,22 @@ async function createSet( | "slug" >, ): Promise { - const { stage_name: _sn, ...rest } = setData; + const insertData: SetInsert = { + name: setData.name, + description: setData.description, + festival_edition_id: setData.festival_edition_id, + stage_id: setData.stage_id, + time_start: setData.time_start, + time_end: setData.time_end, + created_by: setData.created_by, + slug: generateSlug(setData.name), + archived: false, + }; // First, create the set without slug const { data, error } = await supabase .from("sets") - .insert({ - ...rest, - slug: generateSlug(setData.name), - archived: false, // Explicit default - }) + .insert(insertData) .select() .single(); diff --git a/src/hooks/queries/sets/useUpdateSet.ts b/src/hooks/queries/sets/useUpdateSet.ts index 2d39e071..eb47244a 100644 --- a/src/hooks/queries/sets/useUpdateSet.ts +++ b/src/hooks/queries/sets/useUpdateSet.ts @@ -1,26 +1,48 @@ import { useMutation, useQueryClient } from "@tanstack/react-query"; import { useToast } from "@/hooks/use-toast"; import { supabase } from "@/integrations/supabase/client"; +import type { Database } from "@/integrations/supabase/types"; import { generateSlug } from "@/lib/slug"; import { FestivalSet, setsKeys } from "./useSets"; +type SetUpdate = Database["public"]["Tables"]["sets"]["Update"]; + // Mutation function async function updateSet(variables: { id: string; updates: Partial>; }) { const { id, updates } = variables; - const { stage_name: _sn, ...rest } = updates; - // If name is being updated, regenerate slug - const updateData = { ...rest }; - if (updates.name) { + const updateData: SetUpdate = { + updated_at: new Date().toISOString(), + }; + if (updates.name !== undefined) { + updateData.name = updates.name; updateData.slug = generateSlug(updates.name); } + if (updates.description !== undefined) { + updateData.description = updates.description; + } + if (updates.festival_edition_id !== undefined) { + updateData.festival_edition_id = updates.festival_edition_id; + } + if (updates.stage_id !== undefined) { + updateData.stage_id = updates.stage_id; + } + if (updates.time_start !== undefined) { + updateData.time_start = updates.time_start; + } + if (updates.time_end !== undefined) { + updateData.time_end = updates.time_end; + } + if (updates.archived !== undefined) { + updateData.archived = updates.archived; + } const { data, error } = await supabase .from("sets") - .update({ ...updateData, updated_at: new Date().toISOString() }) + .update(updateData) .eq("id", id) .select() .single(); From a9d8501942dfc9d1510edc6010f5f6c96b15ca7c Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 20 May 2026 10:37:19 +0000 Subject: [PATCH 15/18] refactor(queries): flatten update payloads into a single object literal undefined properties are dropped during JSON serialization, so a field absent from the caller's updates is still not written. Only the derived slug needs a conditional. Drops the per-field if guards. https://claude.ai/code/session_01L4WM1ni4NX1mpWUdGkVodk --- src/hooks/queries/artists/useUpdateArtist.ts | 38 ++++++-------------- src/hooks/queries/sets/useUpdateSet.ts | 26 ++++---------- 2 files changed, 17 insertions(+), 47 deletions(-) diff --git a/src/hooks/queries/artists/useUpdateArtist.ts b/src/hooks/queries/artists/useUpdateArtist.ts index 9d27395b..fd0c2cad 100644 --- a/src/hooks/queries/artists/useUpdateArtist.ts +++ b/src/hooks/queries/artists/useUpdateArtist.ts @@ -21,38 +21,20 @@ async function updateArtist(variables: { const updateData: ArtistUpdate = { updated_at: new Date().toISOString(), + name: updates.name, + description: updates.description, + estimated_date: updates.estimated_date, + image_url: updates.image_url, + soundcloud_url: updates.soundcloud_url, + spotify_url: updates.spotify_url, + stage: updates.stage, + time_start: updates.time_start, + time_end: updates.time_end, + archived: updates.archived, }; if (updates.name !== undefined) { - updateData.name = updates.name; updateData.slug = generateSlug(updates.name); } - if (updates.description !== undefined) { - updateData.description = updates.description; - } - if (updates.estimated_date !== undefined) { - updateData.estimated_date = updates.estimated_date; - } - if (updates.image_url !== undefined) { - updateData.image_url = updates.image_url; - } - if (updates.soundcloud_url !== undefined) { - updateData.soundcloud_url = updates.soundcloud_url; - } - if (updates.spotify_url !== undefined) { - updateData.spotify_url = updates.spotify_url; - } - if (updates.stage !== undefined) { - updateData.stage = updates.stage; - } - if (updates.time_start !== undefined) { - updateData.time_start = updates.time_start; - } - if (updates.time_end !== undefined) { - updateData.time_end = updates.time_end; - } - if (updates.archived !== undefined) { - updateData.archived = updates.archived; - } const { data, error } = await supabase .from("artists") diff --git a/src/hooks/queries/sets/useUpdateSet.ts b/src/hooks/queries/sets/useUpdateSet.ts index eb47244a..9f14f5c1 100644 --- a/src/hooks/queries/sets/useUpdateSet.ts +++ b/src/hooks/queries/sets/useUpdateSet.ts @@ -16,29 +16,17 @@ async function updateSet(variables: { const updateData: SetUpdate = { updated_at: new Date().toISOString(), + name: updates.name, + description: updates.description, + festival_edition_id: updates.festival_edition_id, + stage_id: updates.stage_id, + time_start: updates.time_start, + time_end: updates.time_end, + archived: updates.archived, }; if (updates.name !== undefined) { - updateData.name = updates.name; updateData.slug = generateSlug(updates.name); } - if (updates.description !== undefined) { - updateData.description = updates.description; - } - if (updates.festival_edition_id !== undefined) { - updateData.festival_edition_id = updates.festival_edition_id; - } - if (updates.stage_id !== undefined) { - updateData.stage_id = updates.stage_id; - } - if (updates.time_start !== undefined) { - updateData.time_start = updates.time_start; - } - if (updates.time_end !== undefined) { - updateData.time_end = updates.time_end; - } - if (updates.archived !== undefined) { - updateData.archived = updates.archived; - } const { data, error } = await supabase .from("sets") From 96421d03cc09170d1b697d647a8fb94eaccc1b34 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 20 May 2026 10:45:57 +0000 Subject: [PATCH 16/18] fix(scripts): feed bootstrap SQL via stdin so psql interpolates :'email' psql -c sends the string straight to the server without running the variable-interpolation lexer, so :'email' was passed literally. Reading the statement from stdin lets psql substitute and safely quote it. https://claude.ai/code/session_01L4WM1ni4NX1mpWUdGkVodk --- scripts/recreate-staging.sh | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/scripts/recreate-staging.sh b/scripts/recreate-staging.sh index 722a9b91..6686ac53 100755 --- a/scripts/recreate-staging.sh +++ b/scripts/recreate-staging.sh @@ -122,8 +122,9 @@ if [[ -z "$USER_ID" ]]; then fi echo "→ Promoting '$ADMIN_EMAIL' to super_admin…" -psql "$STAGING_DB_URL" -v ON_ERROR_STOP=1 -v email="$ADMIN_EMAIL" \ - -c "SELECT public.bootstrap_super_admin(:'email');" +psql "$STAGING_DB_URL" -v ON_ERROR_STOP=1 -v email="$ADMIN_EMAIL" <<'SQL' +SELECT public.bootstrap_super_admin(:'email'); +SQL cat < Date: Wed, 20 May 2026 16:05:46 +0000 Subject: [PATCH 17/18] refactor(queries): narrow update mutation input types to writable columns updateSet/updateArtist whitelist fields when building the payload, but their parameter types still advertised columns (created_by, id, slug, added_by, ...) that were silently dropped. Narrow the input types to a Pick of the actually-writable columns so unsupported fields are caught at the call site. SetFormDialog now adds created_by only on create. https://claude.ai/code/session_01L4WM1ni4NX1mpWUdGkVodk --- src/hooks/queries/artists/useUpdateArtist.ts | 16 ++++++++++++++-- src/hooks/queries/sets/useUpdateSet.ts | 20 +++++++++++++++----- src/pages/admin/festivals/SetFormDialog.tsx | 6 ++++-- 3 files changed, 33 insertions(+), 9 deletions(-) diff --git a/src/hooks/queries/artists/useUpdateArtist.ts b/src/hooks/queries/artists/useUpdateArtist.ts index fd0c2cad..3e24c2b0 100644 --- a/src/hooks/queries/artists/useUpdateArtist.ts +++ b/src/hooks/queries/artists/useUpdateArtist.ts @@ -8,8 +8,20 @@ import { Artist, artistsKeys } from "./useArtists"; type ArtistUpdate = Database["public"]["Tables"]["artists"]["Update"]; export type UpdateArtistUpdates = Partial< - Omit & { genre_ids: string[] } ->; + Pick< + ArtistUpdate, + | "name" + | "description" + | "estimated_date" + | "image_url" + | "soundcloud_url" + | "spotify_url" + | "stage" + | "time_start" + | "time_end" + | "archived" + > +> & { genre_ids?: string[] }; // Mutation function async function updateArtist(variables: { diff --git a/src/hooks/queries/sets/useUpdateSet.ts b/src/hooks/queries/sets/useUpdateSet.ts index 9f14f5c1..734a6103 100644 --- a/src/hooks/queries/sets/useUpdateSet.ts +++ b/src/hooks/queries/sets/useUpdateSet.ts @@ -3,15 +3,25 @@ import { useToast } from "@/hooks/use-toast"; import { supabase } from "@/integrations/supabase/client"; import type { Database } from "@/integrations/supabase/types"; import { generateSlug } from "@/lib/slug"; -import { FestivalSet, setsKeys } from "./useSets"; +import { setsKeys } from "./useSets"; type SetUpdate = Database["public"]["Tables"]["sets"]["Update"]; +export type UpdateSetInput = Partial< + Pick< + SetUpdate, + | "name" + | "description" + | "festival_edition_id" + | "stage_id" + | "time_start" + | "time_end" + | "archived" + > +>; + // Mutation function -async function updateSet(variables: { - id: string; - updates: Partial>; -}) { +async function updateSet(variables: { id: string; updates: UpdateSetInput }) { const { id, updates } = variables; const updateData: SetUpdate = { diff --git a/src/pages/admin/festivals/SetFormDialog.tsx b/src/pages/admin/festivals/SetFormDialog.tsx index 16a28ccc..8036ed61 100644 --- a/src/pages/admin/festivals/SetFormDialog.tsx +++ b/src/pages/admin/festivals/SetFormDialog.tsx @@ -153,7 +153,6 @@ export function SetFormDialog({ data.stage_id && data.stage_id !== "none" ? data.stage_id : null, time_start: data.time_start ? toISOString(data.time_start) : null, time_end: data.time_end ? toISOString(data.time_end) : null, - created_by: user.id, }; let setId: string; @@ -164,7 +163,10 @@ export function SetFormDialog({ }); setId = updatedSet.id; } else { - const newSet = await createSetMutation.mutateAsync(submitData); + const newSet = await createSetMutation.mutateAsync({ + ...submitData, + created_by: user.id, + }); setId = newSet.id; } From 1999691a358d1b2bae083a285c72466b076f69af Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 20 May 2026 16:35:37 +0000 Subject: [PATCH 18/18] refactor(queries): drop redundant updated_at from updateSet The sets table has an update_updated_at_column() trigger (update_sets_updated_at), so setting updated_at in the mutation payload is redundant. The artists table lacks that trigger -- tracked in #38. https://claude.ai/code/session_01L4WM1ni4NX1mpWUdGkVodk --- src/hooks/queries/sets/useUpdateSet.ts | 1 - 1 file changed, 1 deletion(-) diff --git a/src/hooks/queries/sets/useUpdateSet.ts b/src/hooks/queries/sets/useUpdateSet.ts index 734a6103..dab4d7f0 100644 --- a/src/hooks/queries/sets/useUpdateSet.ts +++ b/src/hooks/queries/sets/useUpdateSet.ts @@ -25,7 +25,6 @@ async function updateSet(variables: { id: string; updates: UpdateSetInput }) { const { id, updates } = variables; const updateData: SetUpdate = { - updated_at: new Date().toISOString(), name: updates.name, description: updates.description, festival_edition_id: updates.festival_edition_id,