Les réglages par défaut de SQLite relancent le débat sur des « éditions » façon Rust

Un billet de blog discuté sur r/programming soutient que SQLite gagnerait à adopter des « éditions » façon Rust : des préréglages versionnés de pragmas regroupant des valeurs par défaut plus sûres, à l'image des éditions Rust (par exemple edition 2025) qui regroupent des changements de langage sans casser le code existant. L'auteur pointe plusieurs comportements par défaut de SQLite qui piègent régulièrement les développeurs : les contraintes de clé étrangère ne sont pas appliquées sauf activation explicite, le mode journal_mode par défaut peut nuire aux performances ou à la durabilité selon l'usage, et le comportement par défaut de verrouillage/busy peut ressembler à une mauvaise gestion des écritures concurrentes alors qu'il s'agit simplement d'un réglage.

Un point précis concerne le délai « busy » : SQLite renvoie rapidement SQLITE_BUSY en cas de conflit d'écriture, sauf si un délai plus long est configuré, par exemple via l'appel API C sqlite3_busy_timeout(db, 5000) ou le pragma équivalent. Des commentateurs ont noté que l'appel API est préférable car il passe par le propre ordonnancement de SQLite plutôt que de le contourner.

Les réactions ont été partagées. Plusieurs développeurs ont dit avoir perdu des heures à déboguer des problèmes causés par ces défauts et ont accueilli favorablement l'idée d'un « super pragma » unique pour activer un comportement moderne. Les critiques ont rétorqué que des éditions nommées (par exemple « edition 2025 ») masquent quels réglages sont réellement actifs, que de bons défauts sont par nature difficiles à choisir (un délai d'écriture de 5 secondes a paru absurdement long à certains), et que les développeurs devraient simplement apprendre les pragmas existants plutôt qu'ajouter une nouvelle couche de versionnement — citant la bande dessinée XKCD sur les « standards » (xkcd.com/927) comme mise en garde contre la création d'une énième convention concurrente. D'autres ont rejeté l'idée comme une « rustification » inutile d'une base de données embarquée légère, mentionnant Turso comme alternative déjà compatible SQLite pour ceux qui souhaitent des défauts différents.