Discussion :

[Olivier Famien]

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

Un peu plus d’un mois après la sortie de la version 3.17 de SQLite, les développeurs de ce moteur de base de données légère viennent de sortir une nouvelle itération de l’outil. Avec pour référence 3.18, la nouvelle version de SQLite intègre plusieurs nouvelles fonctionnalités et vient avec cinq correctifs de bogues.

Au titre des améliorations qui ont trouvé leur place dans cette nouvelle version, un des éléments les plus importants est l’ajout de la commande PRAGMA optimize. Cette commande permet d’optimiser la base de données afin d’avoir de bonnes performances pour les requêtes sans être obligé de parcourir les méandres du code SQL ou du schéma de l’application. Pour tirer profit de cette commande, les applications devront exécuter cette commande sans arguments juste avant de fermer chaque connexion de base de données.

Et si le moteur de base de données est utilisé pendant plusieurs heures d’affilée, les utilisateurs peuvent planifier l’exécution de cette commande à des heures fixes. Toutefois, pour ceux qui pourraient se sentir agacer par le long temps mis par PRAGMA optimize, il est possible d’utiliser d’une minuterie pour interrompre son exécution. À côté de cette commande, nous avons un changement de l’identifiant source de SQLite qui utilise maintenant un hachage SHA3-256 de 64 chiffres au lieu du hachage SHA1 de 40 chiffres.

À cela, il faut ajouter une amélioration de la famille d’interfaces sqlite3_mprintf et la famille de fonctions printf_SQL dans cette version 3.18 afin de pouvoir mettre des séparateurs de virgule aux marques de milliers pour les entiers, si le modificateur de format « , » est utilisé entre « % » et « d ». Par ailleurs, la fonction SQL json_patch a été ajoutée à l’extension JSON1_extension. Pour les autres intégrations, l’on a en plus des éléments qui viennent d’être cités, la commande .sha3sum utilisée pour calculer le hachage du contenu des bases de données et la commande .selftest utilisée pour vérifier qu’une base de données est intacte et non corrompue qui ont été ajoutées à l’interpréteur des lignes de commandes.

Comme autres ajouts, nous avons également l’amélioration des plans pour les jointures SQL afin de détecter des tables vides assez tôt de sorte à interrompre les tâches pour ne pas exécuter de charge inutilement et parallèlement, nous avons l’intégration de l’option de temps de compilation SQLITE_MAX_MEMORY=N pour limiter le temps total de la mémoire dont SQLite demandera à la routine malloc() pour N octets. En outre, pour s’assurer que l’interface sqlite_last_insert_rowid renvoie toujours une valeur raisonnable, cette dernière a été ajoutée dans cette nouvelle version et il est recommandé de l’utiliser dans les extensions FTS3, FTS4 et FTS5 qui sont en fait des modules de table visuelle permettant des recherches de textes dans des documents ou applications.

Au niveau des correctifs, nous avons par exemple une erreur de segmentation qui a été détectée et corrigée dans les déclencheurs récursifs complexes ; pour l’extension RBU utilisée pour mettre à jour ou optimiser de larges fichiers de bases de données sur des appareils à faible consommation énergétique, il est demandé d’ajouter des opérations de synchronisation supplémentaires afin d’éviter une corruption éventuelle en cas de panne électrique.

Plusieurs autres améliorations et correctifs de bogues sont également disponibles.

Source : SQLite

Et vous ?

Que pensez-vous de ces nouvelles fonctionnalités ?

Avez-vous utilisé cette nouvelle version de SQLite ? En êtes-vous satisfaits ?

Voir aussi

Le moteur de base de données SQLite est disponible en version 3.17 avec des améliorations de performance à plusieurs niveaux et trois correctifs
Un développeur évoque cinq raisons pour vous faire utiliser SQLite en 2016, que pensez-vous de ses arguments ?

Forum SGBD, Forum SQLite, Cours et Tutoriels SGBD, FAQ SGBD

[NSKis]

Et au final, on ne dispose toujours pas dans la version de base d'un chiffrement du fichier de données??? On se retrouve avec un fichier indiquant en clair toutes les données saisies dans la base de données lisibles par n'importe quel éditeur de texte...Toujours obligé de passer en mode "bricolage" pour avoir un sqlite3 chiffré (se mettre à compiler soit même du source ou payer un fournisseur dont on ne connait pas la probité)?

Est-ce que je me trompe?

Est-ce qu'avec ce changement au niveau du hachage une base de données créée avec une ancienne version est toujours lisible?