Prise en charge de fonctions mathématiques
Malgré sa puissance et le fait qu'il soit largement utilisé, SQLite est longtemps resté dépourvu de fonctions mathématiques, comme sqrt(), log() et pow(). Si vous vous retrouvez dans le besoin, alors vous devriez les implémenter vous-mêmes. Les développeurs de la bibliothèque se justifiaient par la phrase suivante : « SQLite est appelé 'lite' pour une raison. Si vous avez besoin de fonctions, ajoutez-les vous-même ». Une position jugée pour le moins compréhensible. Peut-être que les développeurs de SQLite préfèrent se concentrer sur les fonctionnalités plus "utiles" ou commerciales. Quoi qu'il en soit, après 20 ans, nous avons maintenant des fonctions mathématiques. Voici la liste complète :
- acos(X) ;
- acosh(X) ;
- asin(X) ;
- asinh(X) ;
- atan(X) ;
- atan2(X,Y) ;
- ceil(X) ;
- ceiling(X) ;
- cos(X) ;
- cosh(X) ;
- degrees(X) ;
- exp(X) ;
- floor(X) ;
- ln(X) ;
- log(B,X) ;
- log(X) ;
- log10(X) ;
- log2(X) ;
- mod(X,Y) ;
- pi() ;
- pow(X,Y) ;
- power(X,Y) ;
- radians(X) ;
- sin(X) ;
- sinh(X) ;
- sqrt(X) ;
- tan(X) ;
- tanh(X) ;
- trunc(X).
Ajout du support pour ALTER TABLE DROP COLUMN
SQLite stocke le schéma sous forme de texte brut dans la table sqlite_schema. La commande DROP COLUMN (ainsi que toutes les autres variantes de ALTER TABLE) modifie ce texte et tente ensuite de réécrire l'intégralité du schéma. La commande ne réussit que si le schéma est toujours valide après la modification du texte. Dans le cas de la commande DROP COLUMN, le seul texte modifié est la suppression de la définition de la colonne dans l'instruction CREATE TABLE. Plus précisément, elle est utilisée pour supprimer une colonne existante d'une table.
Elle supprime la colonne nommée de la table, et réécrit son contenu pour purger les données associées à cette colonne. Par ailleurs, la commande DROP COLUMN échouera s'il existe des traces de la colonne dans d'autres parties du schéma, ce qui empêchera l'analyse du schéma après la modification de l'instruction CREATE TABLE. Autrement dit, la commande DROP COLUMN ne fonctionne que si la colonne n'est pas référencée par d'autres parties du schéma, si elle n'est pas une CLÉ PRIMAIRE et si elle n'a pas de contrainte UNIQUE. Les raisons possibles pour lesquelles la commande DROP COLUMN peut échouer sont les suivantes :
- la colonne est une clé primaire ou une partie de celle-ci ;
- la colonne est soumise à une contrainte UNIQUE ;
- la colonne est indexée ;
- la colonne est nommée dans la clause WHERE d'un index partiel ;
- la colonne est nommée dans une contrainte CHECK de table ou de colonne non associée à la colonne à supprimer ;
- la colonne est utilisée dans une contrainte de clé étrangère ;
- la colonne est utilisée dans l'expression d'une colonne générée ;
- la colonne apparaît dans un déclencheur ou une vue.
Utilisez moins de mémoire lors de l'exécution de VACUUM
La commande VACUUM reconstruit le fichier de la base de données, en l'empaquetant dans une quantité minimale d'espace disque. Selon les développeurs de SQLite, il a plusieurs raisons pour lesquelles une application peut faire cela. 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 restauration ou un fichier journal WAL (Write-Ahead Logging) est utilisé comme il le serait pour toute autre transaction de base de données.
Cela signifie que lors de l'exécution de VACUUM sur 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. En raison des améliorations de performance intervenues dans SQLite, vous utiliserez désormais moins de mémoire lors de l'exécution de VACUUM sur des bases de données contenant de très grandes valeurs TEXT ou BLOB. En effet, il n'est plus nécessaire de conserver en même temps l'intégralité du TEXTE ou du BLOB en mémoire.
Autres changements dans SQLite 3.35
- ajout de la prise en charge de la clause RETURNING sur les instructions DELETE, INSERT et UPDATE ;
- ajout de la prise en charge des indications MATERIALIZED et NOT MATERIALIZED lors de la spécification d'expressions de tables communes. Le comportement par défaut était auparavant NOT MATERIALIZED, mais il est maintenant changé en MATERIALIZED pour les CTE qui sont utilisés plus d'une fois ;
- les paramètres SQLITE_DBCONFIG_ENABLE_TRIGGER et SQLITE_DBCONFIG_ENABLE_VIEW sont modifiés de sorte qu'ils contrôlent uniquement les déclencheurs et les vues dans le schéma de base de données principal ou dans les schémas de base de données attachés et non dans le schéma TEMP. Les déclencheurs et les vues TEMP sont toujours autorisés.
Améliorations du planificateur/optimiseur de requêtes
- améliorations de l'optimisation min/max afin qu'elle fonctionne mieux avec l'opérateur IN et l'optimisation OP_SeekScan de la version précédente ;
- tentative de traitement des opérateurs EXISTS dans la clause WHERE comme s'ils étaient des opérateurs IN, dans les cas où cette transformation est valide et semble susceptible d'améliorer les performances ;
- permettre aux sous-requêtes UNION ALL d'être aplaties même si la requête parente est une jointure ;
- utiliser un index, si nécessaire, sur les expressions IS NOT NULL dans la clause WHERE, même si STAT4 est désactivé ;
- les expressions de la forme "x IS NULL" ou "x IS NOT NULL" peuvent être converties en simples FALSE ou TRUE, si "x" est une colonne qui a une contrainte "NOT NULL" et n'est pas impliquée dans une jointure externe ;
- éviter de vérifier les contraintes de clé étrangère sur une instruction UPDATE si l'UPDATE ne modifie aucune colonne associée à la clé étrangère ;
- autoriser les termes WHERE à être poussés vers le bas dans des sous-requêtes qui contiennent des fonctions de fenêtre, tant que le terme WHERE est entièrement composé de constantes et de copies d'expressions trouvées dans les clauses PARTITION BY de toutes les fonctions de fenêtre dans la sous-requête.
Améliorations du CLI
- amélioration de la commande ".stats" pour qu'elle accepte les nouveaux arguments "stmt" et "vmstep", ce qui permet d'afficher les statistiques de l'instruction "prepare" et uniquement le nombre d'étapes de la machine virtuelle, respectivement ;
- ajout de la commande ".filectrl data_version" ;
- amélioration des commandes ".once" et ".output" de sorte que, si l'argument de destination commence par "|", l'argument ne doit pas être cité.
Correction de bogues
- correction d'une déréférence potentielle de pointeur NULL lors du traitement d'une instruction SELECT syntaxiquement incorrecte avec une clause WHERE corrélée et une clause "HAVING 0". (Également corrigé dans la version patch 3.34.1) ;
- correction d'un bogue dans l'optimisation de l'opérateur IN de la version 3.33.0 qui peut entraîner une réponse incorrecte ;
- correction des réponses incorrectes de l'opérateur LIKE si le motif se termine par "%" et qu'il existe une clause "ESCAPE '_'".
Source : SQLite 3.35
Et vous ?
Que pensez-vous de SQLite 3.35
Voir aussi
SQLite 3.32.0 est disponible et apporte la prise en charge de l'analyse approximative à l'aide de la commande PRAGMA analysis_limit
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