Skip to content

fix: song_identifiers uniqueness per song — albums map to many songs #34

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
sweetmantech merged 2 commits into from
Jun 11, 2026
Merged

fix: song_identifiers uniqueness per song — albums map to many songs #34

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4db9d83
fix(database): song_identifiers uniqueness per song — albums map to m…
sweetmantech Jun 11, 2026
88d87ef
fix(database): drop the old unique constraint by catalog lookup, not …
sweetmantech Jun 11, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions supabase/migrations/20260611120000_fix_song_identifiers_album_uniqueness.sql
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
-- Fix (recoupable/chat#1794): the unique constraint on song_identifiers was
-- (platform, identifier_type, value), which is right for track ids (one
-- external id = one recording) but wrong for album ids — an album contains
-- many songs, so (spotify, album_id, <album>) must exist once PER SONG.
-- The old constraint silently capped every album at one mapped song, which is
-- why GET /playcounts served 1 of 18 tracks.
--
-- The old constraint was declared inline in 20260610010000, so its name is
-- Postgres-generated — drop the table's (single) unique constraint by lookup
-- instead of by name.

DO $$
DECLARE
old_constraint text;
BEGIN
SELECT conname INTO old_constraint
FROM pg_constraint
WHERE conrelid = 'public.song_identifiers'::regclass
AND contype = 'u';

@cubic-dev-ai cubic-dev-ai Bot Jun 11, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: Constraint lookup is too broad and may drop the wrong unique constraint.

Prompt for AI agents 
Check if this issue is valid — if so, understand the root cause and fix it. At supabase/migrations/20260611120000_fix_song_identifiers_album_uniqueness.sql, line 19:

<comment>Constraint lookup is too broad and may drop the wrong unique constraint.</comment>

<file context>
@@ -5,15 +5,29 @@
+  SELECT conname INTO old_constraint
+  FROM pg_constraint
+  WHERE conrelid = 'public.song_identifiers'::regclass
+    AND contype = 'u';
 
+  IF old_constraint IS NOT NULL THEN
</file context>
Suggested change
AND contype = 'u';
AND contype = 'u'
AND pg_get_constraintdef(oid) = 'UNIQUE (platform, identifier_type, value)';


IF old_constraint IS NOT NULL THEN
EXECUTE format('ALTER TABLE public.song_identifiers DROP CONSTRAINT %I', old_constraint);
END IF;
END $$;

-- New uniqueness: one mapping per (song, platform, identifier_type, value).
ALTER TABLE public.song_identifiers
ADD CONSTRAINT song_identifiers_song_platform_type_value_unique
UNIQUE (song, platform, identifier_type, value);

-- Reverse lookups (value -> songs) keep an index, now non-unique.
CREATE INDEX idx_song_identifiers_lookup
ON public.song_identifiers (platform, identifier_type, value);