Changeset 8151340 in Klonkt for src/config/database.js

Timestamp:

09/04/2026 12:05:08 PM (4 days ago)

Author:

Robin <roboburr@…>

Branches:

main

Children:

9946a68

Parents:

aa521c3

Message:

Tijdstempels, leeskant: sorteren op tijd en niet op tekst (shaer-a937)

Deze database draagt twee spellingen door elkaar: '2026-08-06 09:02:01'
van CURRENT_TIMESTAMP en '2026-08-06T02:08:01.000Z' van toISOString().
SQLite vergelijkt tekst, en op positie 10 staat een T tegenover een
spatie -- dus binnen dezelfde dag wint de ISO-vorm altijd, hoe laat hij
ook is. Gemeten op dev: ap_timeline 80 ISO tegen 80 SQL, ap_mentions 26
tegen 38, ap_interactions 2 tegen 6. De menging is er dus echt.

De helper bestond al (STEMPEL in ap-timeline, gebouwd voor de
gesprekslezing) maar stond in een dienst, terwijl elke plek die sorteert
hem nodig heeft. Hij staat nu als isoSql in config/database.js -- daar
hoort hij, want het gaat over hoe deze OPSLAG met tijd omgaat, en elke
aanroeper importeert db toch al. STEMPEL is er nu een verwijzing naar,
zodat er niet twee kopieen van dezelfde regel bestaan.

Genormaliseerd waar de menging LEEFT: de tijdlijn zelf, de reacties
onder een post (de fout die de bead mat), de berichten en de Cirkel.
Plus de archief-export, die op dezelfde kolommen sorteert.

De terugval blijft de RAUWE waarde en niet leeg: isoSql levert ook de
cursor in de gesprekslezing, en een lege stempel zou een client zijn
plek kosten. Waar een onleesbare waarde dan landt is onbepaald, en dat
staat nu ook zo in het commentaar -- eerst schreef ik daar dat zoiets
onderaan hoort te eindigen, en dat deed de code niet.

Vier toetsen met gemengde data, ISO bewust VROEGER op de dag: precies de
stand waarin een ongenormaliseerde sortering omvalt. Tegenbewijs: maak
isoSql een doorgeefluik en alle vier vallen.

Volle suite 1248 groen.

File:

• src/config/database.js (modified) (1 diff)

src/config/database.js

@@ -21 +21 @@
 db.pragma('busy_timeout = 5000');   // wait up to 5s for a lock instead of failing immediately
 db.pragma('synchronous = NORMAL');  // safe with WAL (no torn writes); fewer fsyncs = faster writes
+
+/**
+ * Tijdstempels in EEN spelling (shaer-a937).
+ *
+ * Deze database draagt twee vormen door elkaar: '2026-08-06 09:02:01' van
+ * CURRENT_TIMESTAMP en '2026-08-06T02:08:01.000Z' van toISOString(). SQLite
+ * vergelijkt ze als TEKST, en op positie 10 staat een 'T' (0x54) tegenover een
+ * spatie (0x20) -- dus binnen dezelfde dag wint de ISO-vorm altijd, hoe laat hij
+ * ook is. Een antwoord van 02:08 kwam zo boven een like van 09:02 te staan.
+ *
+ * `NU_ISO` is wat je SCHRIJFT, `isoSql()` is waarmee je VERGELIJKT of SORTEERT.
+ * De twee horen bij elkaar: het eerste zorgt dat er niets nieuws bijkomt, het
+ * tweede dat wat er al staat toch goed op volgorde komt.
+ *
+ * isoSql valt met COALESCE terug op de RAUWE waarde: strftime geeft NULL op iets
+ * dat het niet als tijd herkent, en zonder die terugval zou zo'n rij uit de
+ * sortering vallen -- of erger, als hij ook geSELECTeerd wordt (de cursor in de
+ * gesprekslezing) zou de client een lege stempel terugkrijgen en zijn plek
+ * kwijtraken. Waar zo'n onleesbare waarde dan LANDT is onbepaald: hij wordt als
+ * tekst vergeleken en 'geen datum' staat nu eenmaal boven '2026-...'. Dat is de
+ * juiste ruil -- data die je niet begrijpt bewaar je, je gooit hem niet weg.
+ *
+ * Ze staan HIER en niet in een dienst omdat ze over de opslag gaan: elke plek
+ * die sorteert importeert `db` toch al uit dit bestand.
+ */
+export const NU_ISO = "strftime('%Y-%m-%dT%H:%M:%SZ','now')";
+export const isoSql = (expr) => `COALESCE(strftime('%Y-%m-%dT%H:%M:%SZ', ${expr}), ${expr})`;
 
 export function initializeDatabase() {