Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

SQLite 3.32.0 est disponible et apporte la prise en charge de l'analyse approximative
à l'aide de la commande PRAGMA analysis_limit

Le , par Bill Fassinou

130PARTAGES

3  0 
SQLite est une petite bibliothèque C mettant en œuvre un moteur de base de données SQL autonome, intégrable et sans configuration. Une nouvelle version de SQLite vient d’être publiée avec de nouvelles fonctionnalités et quelques améliorations. SQLite v3.32.0 introduit l’ANALYSE approximative à l’aide de la commande PRAGMA analysis_limit, une table virtuelle pour les codes d'octet, la nouvelle fonction iif(), etc. Les améliorations concernent principalement l'interface CLI. Voici ci-dessous un aperçu des nouveautés de SQLite v3.32.0.

Prise en charge de l'analyse approximative pour les grandes bases de données

Par défaut, ANALYZE effectue un balayage complet de chaque index. Cela peut être lent pour les bases de données volumineuses. Ainsi, à partir de la version 3.32.0 de SQLite, la commande PRAGMA analysis_limit peut être utilisée pour limiter la quantité d'analyse effectuée par ANALYZE. De ce fait, elle aide ANALYZE à fonctionner plus rapidement, même sur des fichiers de base de données très volumineux. Il s’agit en effet « d’exécuter une ANALYSE approximative ». L’utilisation recommandée pour PRAGMA analysis_limit est le suivant : « PRAGMA analysis_limit=1000; ».


Ce PRAGMA indique à la commande ANALYZE de lancer un balayage complet de l'index comme elle le ferait en temps normal. Mais lorsque le nombre de lignes visitées atteint 1000 (ou toute autre limite spécifiée par le PRAGMA), la commande ANALYZE commencera à prendre des mesures pour arrêter l'analyse. Si la colonne la plus à gauche de l'index a changé au moins une fois au cours des 1000 étapes précédentes, alors l'analyse s'arrête immédiatement. Mais si la colonne la plus à gauche a toujours été la même, alors ANALYZE passe à la première entrée avec une colonne différente et lit 1000 lignes supplémentaires avant de se terminer.

Ajout de la table virtuelle des codes d'octet

Bytecode et tables_used constituent des tables virtuelles intégrées à SQLite qui permettent d'accéder à des informations sur les déclarations préparées. Bytecode et tables_used fonctionnent toutes deux comme des fonctions à valeur de table. Ils prennent un seul argument requis qui est soit le texte d'une instruction SQL, soit un pointeur vers une instruction préparée existante. La fonction bytecode renvoie une ligne de résultat pour chaque opération bytecode dans la déclaration préparée. La fonction tables_used renvoie une ligne pour chaque arbre persistant (soit une table, soit un index) auquel la déclaration préparée accède.

Le shim de contrôle VFS checksum

L'extension VFS checksum est un shim VFS qui ajoute une checksum de huit (8) octets à la fin de chaque page d'une base de données SQLite. La somme de contrôle est ajoutée au fur et à mesure que chaque page est écrite et est vérifiée et au fur et à mesure que chaque page est lue. La checksum est destinée à aider à détecter la corruption de la base de données causée par des inversions de bits aléatoires dans le périphérique de stockage de masse. L'extension VFS checksum nécessite la version 3.32.0 de SQLite ou une version ultérieure. Elle ne fonctionnera pas avec les versions antérieures de SQLite.

Ajout de la fonction SQL iif()

La fonction iif(X,Y,Z) renvoie la valeur Y si X est vrai, et Z sinon. La fonction iif(X,Y,Z) est logiquement équivalente à l'expression CASE “CAS WHEN X THEN Y ELSE Z END” et génère le même bytecode.

Les instructions INSERT et UPDATE appliquent maintenant l'affinité des colonnes avant de calculer les contraintes CHECK

Les moteurs de base de données SQL qui utilisent une typographie rigide tentent généralement de convertir automatiquement les valeurs en un type de données approprié. Afin de maximiser la compatibilité entre les autres moteurs de base de données et SQLite, celui-ci apporte le concept “d'affinité de type” sur les colonnes. L'affinité de type d'une colonne est le type recommandé pour les données stockées dans cette colonne. L'idée importante ici est que le type est recommandé, et non requis. N'importe quelle colonne peut toujours stocker n'importe quel type de données.

Introduction de sqlite3_create_filename(), sqlite3_free_filename() et sqlite3_database_file_object()

Ces trois interférences ont été intégrées pour être utilisées par les implémentations de shims VFS. Selon les explications fournies par l’équipe de développement, elles ne vous sont pas utiles en dehors de ce contexte. sqlite3_create_filename(D,J,W,N,P) alloue de la mémoire pour garder une version du nom de fichier de la base de données D et les fichiers journaux correspondants J et WAL W et avec N paires clé/valeur des paramètres URI dans le tableau P. Le résultat est un pointeur vers un nom de fichier de base de données qui peut être transmis sans danger à des routines.

La routine sqlite3_free_filename(Y) libère une allocation mémoire qui a été précédemment utilisée par sqlite3_create_filename(). Pour cela, invoquez sqlite3_free_filename(Y) où l’argument Y est un pointeur NULL est un no-op inoffensif. Si X est le nom d'un fichier journal en mode rollback ou WAL qui est passé dans la méthode xOpen de sqlite3_vfs, alors le résultat de sqlite3_database_file_object(X) est un pointeur vers l'objet sqlite3_file qui représente le fichier de base de données principal. Elle est conçue uniquement pour les implémentations VFS personnalisées.

Parmi les améliorations apportées à la CLI, il y a :

  • ajout des options --csv, --ascii et --skip à la commande .import ;
  • la commande .dump accepte maintenant de multiples arguments de type LIKE et produit l'union de toutes les tables correspondantes ;
  • ajout de la commande .oom dans les builds de débogage ;
  • ajout de l'option --bom aux commandes .excel, .output et .once ;
  • amélioration de la commande .filectrl pour qu'elle prenne en charge l'option --schema ;
  • l'extension de la séquence d'assemblage UINT est automatiquement chargée.

Il s’agit là des fonctionnalités et des améliorations les plus notables de cette version. SQLite v3.32.0 introduit aussi plusieurs autres fonctions, dont l’ajout d'un code pour la séquence de collationnement UINT comme extension optionnelle chargeable ; l’augmentation de la limite supérieure par défaut du nombre de paramètres de 999 à 32766.

Source : Note de version de SQLite v3.32.0

Et vous ?

Que pensez-vous des nouveautés de SQLite 3.32.0 ?

Voir aussi

La version 3.28 de SQLite est disponible avec de nouvelles fonctionnalités et des améliorations de performances, notamment pour les fonctions Window

SQLite 3.25 est disponible, le moteur de base de données léger apporte le support des fonctions Window, un meilleur optimiseur de requêtes et plus

SQLite est 35 % plus rapide que le système de fichiers, selon les tests des développeurs du moteur de base de données

La version 3.18 de SQLite est disponible avec un nouvel identifiant utilisant le hachage SHA3-256 et l'ajout de la commande PRAGMA optimize

Une erreur dans cette actualité ? Signalez-le nous !