Skip to content

⚡ Bolt: Optimized playlist song fetching with innerJoin #71

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
Krosebrook merged 2 commits into from
Mar 3, 2026
+1 −1
Merged

⚡ Bolt: Optimized playlist song fetching with innerJoin #71

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3de8b62
⚡ Bolt: Optimized playlist song fetching with innerJoin
google-labs-jules[bot] Feb 19, 2026
9efd27c
Merge branch 'main' into bolt/optimize-playlist-fetching-137935291942…
Krosebrook Mar 3, 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
2 changes: 1 addition & 1 deletion server/storage.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -140,7 +140,7 @@ export class DatabaseStorage implements IStorage {
.from(songs)
.innerJoin(songLikes, eq(songs.id, songLikes.songId))
.where(eq(songLikes.userId, userId))
.orderBy(desc(songLikes.createdAt).nullsLast());
.orderBy(desc(songLikes.createdAt));
Copy link
Contributor

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

Choose a reason for hiding this comment

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

medium

Removing .nullsLast() changes the sorting behavior for liked songs that might have a null createdAt value. With this change, songs with a null creation date will appear at the top of the list when sorted in descending order (this is the default for PostgreSQL), which is likely not the desired user experience, as the createdAt column in the songLikes table is nullable.

While the PR description mentions this was to fix a type error, altering the query's logic could introduce this unintended behavior. If .nullsLast() is indeed causing a type error, you could consider using a raw SQL fragment to achieve the correct sorting behavior while avoiding the type issue.

Suggested change
.orderBy(desc(songLikes.createdAt));
.orderBy(sql`${songLikes.createdAt} desc nulls last`)

Copy link

@cubic-dev-ai cubic-dev-ai bot Feb 19, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

P2: Removing .nullsLast() changes the sorting behavior for liked songs with null createdAt values. In PostgreSQL, nulls sort first in descending order by default, so songs with null creation dates will appear at the top of the list instead of at the end. If the original .nullsLast() was causing a type error, consider using a raw SQL fragment to maintain the intended sorting behavior.

Prompt for AI agents 
Check if this issue is valid — if so, understand the root cause and fix it. At server/storage.ts, line 143:

<comment>Removing `.nullsLast()` changes the sorting behavior for liked songs with `null` `createdAt` values. In PostgreSQL, nulls sort first in descending order by default, so songs with null creation dates will appear at the top of the list instead of at the end. If the original `.nullsLast()` was causing a type error, consider using a raw SQL fragment to maintain the intended sorting behavior.</comment>

<file context>
@@ -140,7 +140,7 @@ export class DatabaseStorage implements IStorage {
       .innerJoin(songLikes, eq(songs.id, songLikes.songId))
       .where(eq(songLikes.userId, userId))
-      .orderBy(desc(songLikes.createdAt).nullsLast());
+      .orderBy(desc(songLikes.createdAt));
   }
 
</file context>
Suggested change
.orderBy(desc(songLikes.createdAt));
.orderBy(sql`${songLikes.createdAt} desc nulls last`);
Fix with Cubic

Copy link

@coderabbitai coderabbitai bot Feb 19, 2026

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor

Removing nullsLast shifts NULL sort position from last → first.

PostgreSQL's DESC defaults to NULLS FIRST; the previous nullsLast wrapper overrode that. Since songLikes.createdAt carries defaultNow() but no .notNull() constraint, null values are schema-permitted. In practice defaultNow() means no rows will have a null createdAt, so the behavioural delta is negligible — but worth keeping in mind if the schema constraint is ever relaxed.

🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In `@server/storage.ts` at line 143, The ORDER BY was changed to use
.orderBy(desc(songLikes.createdAt)) which in PostgreSQL sorts NULLs first;
restore the previous nulls-last behavior by wrapping the sort with the nullsLast
helper (i.e., use nullsLast(desc(songLikes.createdAt))) so nullable createdAt
values remain ordered last; update the ordering in the query that references
songLikes.createdAt to use nullsLast to preserve the original semantics.

⚠️ Potential issue | 🟡 Minor

Removing nullsLast silently changes NULL sort position from LAST → FIRST.

In PostgreSQL, DESC ordering defaults to NULLS FIRST. The previous nullsLast(desc(...)) overrode that default to push NULLs to the end. Since songLikes.createdAt uses defaultNow() but does not declare .notNull(), the column is schema-nullable — null values are permitted even if defaultNow() makes them practically impossible in normal inserts.

The real-world impact is negligible, but if a row is ever inserted with an explicit NULL for createdAt, it will now sort to the top of a user's liked songs list instead of the bottom. Worth adding .notNull() to the schema column to make the intent explicit and lock out that edge case permanently.

🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In `@server/storage.ts` at line 143, The ORDER BY change removed nullsLast which
causes NULLs to sort FIRST for desc(songLikes.createdAt); fix this by making the
schema intent explicit: update the songLikes.createdAt column definition (the
place where defaultNow() is used) to include .notNull() so createdAt cannot be
NULL, and ensure any migration/schema generation includes that constraint (or,
if you prefer preserving behavior instead, reapply
nullsLast(desc(songLikes.createdAt)) in the query); reference
songLikes.createdAt, defaultNow(), .notNull(), and the orderBy call when making
the change.

}

// === Playlists ===
Expand Down