Avete presente quella sensazione di frustrazione quando state cercando di far girare un vecchio progetto e vi accorgete che la versione della libreria che vi serve è incompatibile con tutto il resto del vostro stack? Ecco, SQLite è il pilastro invisibile su cui poggia metà del web e di quasi ogni app che usate, ma ha un piccolo problema: è troppo… stabile. E con ‘stabile’ intendo che è un pezzo di granito che non si muove di un millimetro da decenni.
Recentemente è emersa una proposta (che ha fatto sobbalzare i commenti su Hacker News) piuttosto intrigante: SQLite dovrebbe adottare un sistema di «editions», ispirandosi a quello che ha fatto Rust. Per chi non mastica ancora abbastanza il linguaggio della Mozilla, le editions permettono di evolvere il linguaggio senza rompere il codice scritto anni fa. È un modo per dire: «Ehi, vogliamo aggiungere feature fighe senza mandare tutto in crash a chi usa la versione legacy».
L’idea è potente. Immaginate di poter scegliere una versione di SQLite ottimizzata per l’embedded, una per le performance estreme su server massicci, o una con configurazioni specifiche per la sicurezza, il tutto mantenendo una compatibilità di base che non vi faccia venire l’orticaria. In pratica, si tratterebbe di gestire diverse configurazioni del motore senza dover gestire un incubo di fork o di flag di compilazione infiniti e poco documentati.
Certo, c’è chi potrebbe obiettare che SQLite è SQLite e che toccare la sua struttura è come cercare di hackerare il mainframe di SHIELD senza lasciare tracce: un suicidio. Il rischio è quello di creare una frammentazione che renderebbe la manutenzione un incubo per chi, come noi, preferisce la semplicità del ‘funziona e basta’.
Non è una questione che riguarda solo noi nerd in ufficio con le magliette di Star Trek. Anche se le decisioni di sviluppo avvengono in contesti globali, l’impatto sulla nostra infrastitura locale è enorme. Se il software fondamentale cambia paradigma, cambiano anche i nostri workflow di deployment e di testing.
Speriamo che questa proposta rimanga nell’ambito delle discussioni filosofiche tra accademici e sviluppatori di sistema, a meno che non trovi una via d’uscita elegante. Perché, siamo onesti, l’ultima cosa di cui abbiamo bisogno è dover imparare un nuovo sistema di gestione delle versioni per un database che prima semplicemente ‘era lì’. Ma se riuscissero a farlo senza rompere la retrocompatibilità? Beh, allora sarebbe davvero una cosa da nerd veri.