schema: il limite del vincolo e' la migrazione che non c'e', non SQLite

src/lib/longevity/db.ts

@@ -89,9 +89,16 @@ CREATE TABLE IF NOT EXISTS score (
   -- 'score' direttamente, dove quel tipo non c'e' piu'. Questo vincolo lo riscrive
   -- a livello di dato: o lo stato e' 'ok' e il valore c'e', o e' 'insufficiente' e
   -- il valore e' NULL, mai un numero scritto sotto uno stato che lo nega.
-  -- SQLite non permette di aggiungere un CHECK con ALTER TABLE a una tabella gia'
-  -- creata: un database longevity.db esistente, creato prima di questa modifica,
-  -- NON avra' questo vincolo finche' non viene ricreato.
+  -- ATTENZIONE al limite, che non e' quello che sembra: lo schema qui sopra gira con
+  -- CREATE TABLE IF NOT EXISTS, che su un file gia' esistente e' un'operazione a vuoto.
+  -- Quindi un longevity.db creato prima di questa modifica NON ha questo vincolo, e
+  -- continuera' a non averlo finche' qualcuno non lo migra a mano.
+  -- (Non e' un limite di SQLite: la versione imbarcata da better-sqlite3 e' la 3.53,
+  -- che ALTER TABLE ... ADD CONSTRAINT lo supporta. E' che qui una migrazione non c'e'.
+  -- Verificato il 22/08: la CLI di sistema e' la 3.37 e non lo supporta, quindi provarlo
+  -- da riga di comando da' un errore fuorviante.)
+  -- Oggi nessun longevity.db esiste ancora, quindi il caso e' teorico: lo diventa il
+  -- giorno del primo deploy, ed e' quello il momento di ricordarselo.
   CHECK ((stato = 'ok' AND valore IS NOT NULL) OR (stato = 'insufficiente' AND valore IS NULL))
 );
 CREATE INDEX IF NOT EXISTS idx_score_cliente ON score (client_code, calcolato_at DESC);