SQLite 3.40 est disponible, le moteur de base de données léger apporte le support officiel de Wasm
SQLite 3.40 est disponible, le moteur de base de données léger apporte le support officiel de Wasm,
une API de récupération qui pourrait récupérer une partie du contenu d'un fichier de BD corrompu
L'équipe de développement de SQLite a annoncé le 16 novembre la sortie de la version 3.40 de SQLite. Cette version apporte le support pour compiler SQLite à WASM et l'exécuter dans les navigateurs web. L'annonce de SQLite serait liée à l'enthousiasme de Google pour un SQL dans le navigateur. « Nous travaillons avec la communauté SQLite sur un remplacement pour Web SQL basé sur SQLite implémenté dans WebAssembly (Wasm), qui sera publié dans un avenir proche. Pour les développeurs qui cherchent un remplacement immédiat, nous étudions la possibilité de fournir un script de shim », a déclaré le Dr Thomas Steiner, Ingénieur des relations avec les développeurs chez Google.
SQLite est un moteur de base de données relationnelle léger accessible par le langage SQL. Contrairement aux serveurs de bases de données traditionnels, comme MySQL ou PostgreSQL, sa particularité est de ne pas reproduire le schéma habituel client-serveur, mais d'être directement intégrée aux programmes. L'intégralité de la base de données (déclarations, tables, index et données) est en effet stockée dans un fichier indépendant de la plateforme.
Grâce à son extrême légèreté, SQLite est l’un des moteurs de base de données les plus utilisés au monde. Il est utilisé dans de nombreux logiciels grand public, et est également très populaire sur les systèmes embarqués, notamment sur la plupart des smartphones modernes.
API de récupération
Les bases de données SQLite sont remarquablement robustes. Les défauts d'application et les pannes de courant laissent généralement le contenu de la base de données intact. Cependant, il est possible de compromettre une base de données SQLite. Par exemple, des dysfonctionnements matériels peuvent endommager le fichier de la base de données, ou un processus malveillant peut ouvrir la base de données et modifier des parties.
Dans le cas d'un fichier de base de données corrompu, il est parfois souhaitable d'essayer de récupérer autant de données que possible. L'API de récupération est conçue pour faciliter cette tâche. La version 3.40 de SQLite permet de récupérer en utilisant la commande .recover dans le CLI.
La manière la plus simple de récupérer manuellement une base de données corrompue est d'utiliser l'interface de ligne de commande ou "CLI" pour SQLite. Le CLI est un programme nommé "sqlite3". Utilisez-le pour récupérer un fichier de base de données corrompu en utilisant une commande similaire à la suivante :
sqlite3 corrupt.db .recover >data.sql
Cela générera un texte SQL dans le fichier nommé data.sql qui peut être utilisé pour reconstruire la base de données originale :
sqlite3 recovered.db <data.sql
L'option .recover est en fait une commande émise vers le CLI. Cette commande peut accepter des arguments. Par exemple, en exécutant :
sqlite3 corruptdb ".recover --ignore-freelist" >data.sql
VACUUM avec une clause INTO
Si la clause INTO est incluse, le fichier de la base de données d'origine est inchangé et une nouvelle base de données est créée dans un fichier nommé par l'argument de la clause INTO. La nouvelle base de données contiendra le même contenu logique que la base de données originale, entièrement vidée. La commande VACUUM avec une clause INTO est une alternative à l'API de sauvegarde pour générer des copies de sauvegarde d'une base de données active.
L'avantage de l'utilisation de VACUUM INTO est que la base de données de sauvegarde résultante est de taille minimale et donc la quantité d'E/S du système de fichiers peut être réduite. De plus, tout le contenu supprimé est purgé de la sauvegarde, ne laissant derrière lui aucune trace. D'autre part, l'API de sauvegarde utilise moins de cycles CPU et peut être exécutée de manière incrémentielle.
Le nom de fichier dans la clause INTO peut être une expression SQL arbitraire qui s'évalue en une chaîne de caractères. Le fichier nommé par la clause INTO ne doit pas exister auparavant, ou bien il doit s'agir d'un fichier vide, sinon la commande VACUUM INTO échouera avec une erreur.
Comment fonctionne VACUUM
La commande VACUUM fonctionne en copiant le contenu de la base de données dans un fichier temporaire, puis en écrasant l'original avec le contenu du fichier temporaire. Lors de l'écrasement de l'original, un journal de retour en arrière ou un fichier WAL d'écriture en tête est utilisé comme pour toute autre transaction. Cela signifie que lors de la purge d'une base de données, il faut jusqu'à deux fois la taille du fichier de base de données d'origine en espace disque libre.
La commande VACUUM INTO fonctionne de la même manière, sauf qu'elle utilise le fichier nommé dans la clause INTO à la place de la base de données temporaire et qu'elle omet l'étape de recopie de la base de données nettoyée par-dessus la base de données originale. La commande VACUUM peut modifier les ROWIDs des entrées dans toutes les tables qui n'ont pas de INTEGER PRIMARY KEY explicite.
Un VACUUM échouera s'il existe une transaction ouverte sur la connexion de la base de données qui tente d'exécuter le VACUUM. Les instructions SQL non finalisées maintiennent généralement une transaction de lecture ouverte, de sorte que le VACUUM peut échouer s'il existe des instructions SQL non finalisées sur la même connexion. VACUUM (mais pas VACUUM INTO) est une opération d'écriture et donc si une autre connexion de base de données détient un verrou qui empêche les écritures, alors le VACUUM échouera.
Une alternative à l'utilisation de la commande VACUUM pour récupérer l'espace après que les données ont été supprimées est le mode auto-vacuum, activé en utilisant le pragma auto_vacuum.
SQLite vers WASM
WebAssembly, alias WASM, est une norme définissant un langage de programmation de bas niveau adapté comme cible pour la compilation croisée à partir de nombreux autres langages et pour être exécuté via une machine virtuelle dans un navigateur. Conçu avec la scriptabilité via JavaScript à l'esprit, il fournit un moyen de compiler le code C (parmi d'autres) à WASM et le script via JavaScript avec relativement peu de friction en dépit des grandes différences entre JavaScript et C.
Comme WASM est une technologie centrée sur le web et UTF-8 est le roi des encodages dans ce domaine, l'équipe de développement de SQLite ne prévoit aucun plan pour supporter les API sqlite3 liées à UTF16. « Cela compliquerait les liaisons sans aucun avantage appréciable », indique-t-elle. WASM est construit pour un web moderne et nécessite des plateformes modernes. De même, les options de la bibliothèque sqlite3 qui ont été dépréciées ne sont pas incluses dans l'interface WASM.
L'annonce de SQLite serait liée à l'enthousiasme de Google pour un SQL dans le navigateur. « Nous travaillons avec la communauté SQLite sur un remplacement pour Web SQL basé sur SQLite implémenté dans WebAssembly (Wasm), qui sera publié dans un avenir proche. Pour les développeurs qui cherchent un remplacement immédiat, nous étudions la possibilité de fournir un script de shim », a déclaré le Dr Thomas Steiner, Ingénieur des relations avec les développeurs chez Google.
« Il faut que chaque développeur de navigateur accepte SQLite comme partie intégrante de sa plateforme. Cela peut ne pas être possible pour un certain nombre de raisons, dont la moindre n'est pas que cela signifie essentiellement que chaque navigateur web est à la merci de problèmes de sécurité potentiels au sein de SQLite », a déclaré Vladimir Vukićević, ingénieur logiciel chez Mozilla, en 2009.
« Les premières implémentations de Web Storage sont toutes deux basées sur SQLite, et exposent le dialecte de SQL compris par SQLite au contenu web. Je suis en fait un grand fan de SQLite, et j'étais l'un des défenseurs de son intégration dans la plateforme Gecko », poursuit-il. Toutefois, de l’avis de ses fondateurs, SQLite n'est pas assez ouvert et a besoin d'être modernisé. Un nouveau fork de SQLite, appelé libSQL, vise à répondre à cette préoccupation.
Glauber Costa est fondateur et PDG de ChiselStrike, dont le produit génère des applications back-end à partir de classes TypeScript. Dans ce qu'il appelle le manifeste pour libSQL, lui et son équipe soutiennent que SQLite doit être enrichi de nouvelles fonctionnalités essentielles.
Source : SQLite
Et vous ?
Que pensez-vous de SQLite ? L'utilisez-vous ?
Voir aussi :
Répondre avec citation
Partager