Skip to content

⚡ Bolt: Optimized playlist song fetching #68

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

Open
Krosebrook wants to merge 1 commit into
base: main
Choose a base branch
from
Open

⚡ Bolt: Optimized playlist song fetching #68

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
4 changes: 4 additions & 0 deletions .jules/bolt.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,7 @@
## 2026-02-10 - Atomic Database Updates
**Learning:** Read-modify-write patterns for counters (like `playCount`) cause race conditions and extra DB round trips.
**Action:** Use atomic SQL updates (e.g., `playCount = playCount + 1`) with `returning()` to ensure data integrity and performance.

## 2026-02-25 - N+1 Query Optimization in Playlists
**Learning:** `getPlaylistWithSongs` was using an N+1 pattern (fetching IDs then fetching songs) which caused multiple DB round trips and required manual sorting.
**Action:** Replaced with a single `innerJoin` query using `getTableColumns` and `orderBy(playlistSongs.id)` to fetch songs in insertion order efficiently.
23 changes: 7 additions & 16 deletions server/storage.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -160,24 +160,15 @@ export class DatabaseStorage implements IStorage {
const playlist = await this.getPlaylist(id);
if (!playlist) return undefined;

const playlistSongRows = await db.select({ songId: playlistSongs.songId })
.from(playlistSongs)
.where(eq(playlistSongs.playlistId, id));

const songIds = playlistSongRows.map(r => r.songId).filter(id => typeof id === 'number' && !isNaN(id));

if (songIds.length === 0) {
return { ...playlist, songs: [] };
}

const songsResult = await db.select()
// Optimized: Single query using innerJoin to fetch songs directly in insertion order (by playlistSongs.id)
// This replaces the previous N+1 pattern of fetching IDs then fetching songs
Copy link

Copilot AI Feb 18, 2026

Choose a reason for hiding this comment

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

The comment says this replaces an “N+1 pattern”, but the removed code path executed a fixed number of queries (fetch join-table rows, then fetch songs via inArray). Consider updating the comment to describe it as a “two-step fetch” / “multiple round trips” to avoid misleading future readers.

Suggested change
// This replaces the previous N+1 pattern of fetching IDs then fetching songs
// This replaces the previous two-step fetch (playlistSongs rows, then songs via inArray) to avoid multiple round trips

Copilot uses AI. Check for mistakes.
const songsList = await db.select(getTableColumns(songs))
.from(songs)
Comment on lines +163 to 166
Copy link

Copilot AI Feb 18, 2026

Choose a reason for hiding this comment

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

The new implementation makes inArray unused in this module (it was only used by the removed two-step fetch). Please remove inArray from the drizzle-orm imports to avoid dead code and potential TS build failures under noUnusedLocals/noUnusedParameters.

Copilot uses AI. Check for mistakes.
.where(inArray(songs.id, songIds));

const songMap = new Map(songsResult.map(s => [s.id, s]));
const songsList = songIds.map(id => songMap.get(id)).filter((s): s is Song => !!s);
.innerJoin(playlistSongs, eq(songs.id, playlistSongs.songId))
.where(eq(playlistSongs.playlistId, id))
.orderBy(playlistSongs.id);

return { ...playlist, songs: songsList };
return { ...playlist, songs: songsList as Song[] };
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 18, 2026

Choose a reason for hiding this comment

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

high

The songsList resulting from the innerJoin query with getTableColumns(songs) will be an array of objects where each object contains both songs and playlistSongs properties (e.g., { songs: Song, playlistSongs: PlaylistSong }). A direct type assertion as Song[] is not accurate here, as the structure does not directly match Song[]. This could lead to runtime type mismatches or unexpected data if songsList is consumed expecting only Song objects.

To correctly map the result to an array of Song objects, you should extract the songs property from each row returned by the query.

Suggested change
return { ...playlist, songs: songsList as Song[] };
const songsListRaw = await db.select(getTableColumns(songs))
.from(songs)
.innerJoin(playlistSongs, eq(songs.id, playlistSongs.songId))
.where(eq(playlistSongs.playlistId, id))
.orderBy(playlistSongs.id);
const songsList: Song[] = songsListRaw.map(row => row.songs);
return { ...playlist, songs: songsList };

Comment on lines +169 to +171
Copy link

Copilot AI Feb 18, 2026

Choose a reason for hiding this comment

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

Casting songsList to Song[] bypasses type-safety and can hide shape mismatches (especially with joins/select helpers). Prefer restructuring the query so it naturally returns Song[] (e.g., select songs and map row.songs, or use a typed select shape) and remove the assertion.

Copilot uses AI. Check for mistakes.
}

async createPlaylist(insertPlaylist: InsertPlaylist): Promise<Playlist> {
Expand Down