Problem
createSet in src/hooks/queries/sets/useCreateSet.ts performs a redundant second write:
- The
INSERT already includes slug: generateSlug(setData.name).
- Immediately after, the function runs a second
UPDATE that sets slug = generateSlug(data.name) and writes it back.
generateSlug (src/lib/slug.ts) only depends on its input string — it never uses the row ID. Since data.name === setData.name, the follow-up UPDATE writes the identical value. It's a wasted round-trip, and the "Generate and update the slug using the created ID" comment is stale and misleading.
createArtist already does this correctly: a single insert with the slug, no follow-up update.
Suggested fix
Remove the post-insert slug UPDATE block in createSet and return data directly (with artists: [], votes: []). Drop the misleading comment.
Context
Flagged by Copilot review on PR #34. Tracking separately rather than expanding the db-sync PR scope.
Problem
createSetinsrc/hooks/queries/sets/useCreateSet.tsperforms a redundant second write:INSERTalready includesslug: generateSlug(setData.name).UPDATEthat setsslug = generateSlug(data.name)and writes it back.generateSlug(src/lib/slug.ts) only depends on its input string — it never uses the row ID. Sincedata.name === setData.name, the follow-upUPDATEwrites the identical value. It's a wasted round-trip, and the "Generate and update the slug using the created ID" comment is stale and misleading.createArtistalready does this correctly: a single insert with the slug, no follow-up update.Suggested fix
Remove the post-insert slug
UPDATEblock increateSetand returndatadirectly (withartists: [],votes: []). Drop the misleading comment.Context
Flagged by Copilot review on PR #34. Tracking separately rather than expanding the db-sync PR scope.