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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.