Prisma orderBy na nullable sloupci řadí NULL poslední — „unread first" je obráceně

import { Aside } from ‘@astrojs/starlight/components’;

U orderBy na nullable sloupci vždy explicitně určit chování NULL (`{ sort: "asc", nulls: "first" }`) a časové seznamy řadit primárně dle `createdAt`; „stavové" řazení (přečteno/nepřečteno) řešit vizuálně, ne pořadím.

Symptom

Dropdown notifikací (zvoneček) neukazuje nejnovější položky nahoře. Nepřečtené notifikace, které měly být první, jsou naopak dole; přečtené položky jsou v „náhodném” pořadí. Po pollingu (periodický refetch seznamu) položky pod rukama uživatele přeskakují.

Root cause

Záměr byl „nepřečtené první, pak od nejnovější”:

orderBy: [
  { readAt: "asc" }, // unread (null) first  ← komentář lže
  { createdAt: "desc" },
]

Dva problémy:

1. PostgreSQL řadí NULL při ASC jako POSLEDNÍ (default NULLS LAST). Nepřečtené záznamy (readAt = NULL) tedy skončí na konci, ne na začátku — přesný opak záměru v komentáři.
2. Primární klíč readAt asc znamená, že přečtené záznamy se řadí podle okamžiku přečtení, ne podle vytvoření — createdAt desc se uplatní jen jako tiebreaker. Seznam tak není chronologický a klik na položku (nastaví readAt) ji při dalším pollu přesune jinam.

Fix

Řadit čistě časově; stav přečtení odlišovat vizuálně (barva/tečka), ne pořadím:

// před
orderBy: [{ readAt: "asc" }, { createdAt: "desc" }]

// po
orderBy: [{ createdAt: "desc" }, { id: "desc" }]

Pokud je „unread first” opravdu požadavek, musí být NULL chování explicitní:

orderBy: [
  { readAt: { sort: "asc", nulls: "first" } },
  { createdAt: "desc" },
]

Jak to příště odhalit dřív

• Test na pořadí seznamu s mixem NULL/ne-NULL hodnot v řadicím sloupci.
• Code review checklist: každé orderBy na nullable sloupci musí mít explicitní nulls.
• Pozor na „mutující” řadicí klíče (readAt, updatedAt) u seznamů s pollingem — položky skáčou.