{"id":105659,"date":"2022-11-21T15:36:52","date_gmt":"2022-11-21T13:36:52","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-subd-sqlite-3-40"},"modified":"2022-11-21T15:36:52","modified_gmt":"2022-11-21T13:36:52","slug":"vypusk-subd-sqlite-3-40","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/vypusk-subd-sqlite-3-40","title":{"rendered":"Publication de la base de donn\u00e9es SQLite 3.40","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
La version 3.40 de SQLite a \u00e9t\u00e9 publi\u00e9e, une base de donn\u00e9es l\u00e9g\u00e8re, pr\u00e9sent\u00e9e sous la forme d'une biblioth\u00e8que dynamique. Le code de SQLite est dans le domaine public, ce qui signifie qu'il peut \u00eatre utilis\u00e9 sans limitations et gratuitement \u00e0 toutes fins. Le consortium sp\u00e9cialement cr\u00e9\u00e9 pour soutenir financi\u00e8rement les d\u00e9veloppeurs de SQLite comprend des entreprises telles qu'Adobe, Oracle, Mozilla, Bentley et Bloomberg. <\/p>\n
Principales modifications : <\/p>\n
\n
Une fonctionnalit\u00e9 exp\u00e9rimentale de compilation de SQLite en code interm\u00e9diaire WebAssembly a \u00e9t\u00e9 mise en \u0153uvre, permettant d'\u00eatre ex\u00e9cut\u00e9e dans un navigateur web et appropri\u00e9e pour g\u00e9rer les bases de donn\u00e9es \u00e0 partir d'applications web en JavaScript. Les d\u00e9veloppeurs web b\u00e9n\u00e9ficient d'une interface orient\u00e9e objet de haut niveau pour travailler avec les donn\u00e9es dans le style de sql.js ou Node.js, une couche au-dessus de l'API C de bas niveau et une API bas\u00e9e sur le m\u00e9canisme Web Worker, permettant de cr\u00e9er des gestionnaires asynchrones ex\u00e9cut\u00e9s dans des threads s\u00e9par\u00e9s. Les donn\u00e9es que les applications web sauvegardent dans la version WASM de SQLite peuvent \u00eatre stock\u00e9es c\u00f4t\u00e9 client \u00e0 l'aide d'OPFS (Origin-Private FileSystem) ou de l'API window.localStorage.\n
Une extension de r\u00e9cup\u00e9ration a \u00e9t\u00e9 ajout\u00e9e, destin\u00e9e \u00e0 r\u00e9cup\u00e9rer des donn\u00e9es \u00e0 partir de fichiers corrompus provenant de la base de donn\u00e9es. Dans l'interface de ligne de commande pour la r\u00e9cup\u00e9ration, la commande utilis\u00e9e est «.recover».\n
L'optimisation du planificateur de requ\u00eates a \u00e9t\u00e9 am\u00e9lior\u00e9e. Les limitations d'utilisation des index avec des tables contenant plus de 63 colonnes ont \u00e9t\u00e9 supprim\u00e9es (auparavant, lors des op\u00e9rations sur des colonnes dont le num\u00e9ro ordinal d\u00e9passe 63, l'indexation n'\u00e9tait pas appliqu\u00e9e). L'indexation des valeurs utilis\u00e9es dans les expressions a \u00e9t\u00e9 am\u00e9lior\u00e9e. Le chargement depuis le disque de longues cha\u00eenes et blobs lors du traitement des op\u00e9rateurs NOT NULL et IS NULL a \u00e9t\u00e9 interrompu. La mat\u00e9rialisation des vues pour lesquelles un scan complet n'est effectu\u00e9 qu'une seule fois a \u00e9t\u00e9 exclue.\n
Dans la base de code, au lieu du type «char *» pour repr\u00e9senter les noms de fichiers, un type distinct sqlite3_filename a \u00e9t\u00e9 introduit.\n
Une fonction interne sqlite3_value_encoding() a \u00e9t\u00e9 ajout\u00e9e.\n
Le mode SQLITE_DBCONFIG_DEFENSIVE a \u00e9t\u00e9 ajout\u00e9, interdisant la modification de la version du sch\u00e9ma de stockage des donn\u00e9es.\n
Des v\u00e9rifications suppl\u00e9mentaires ont \u00e9t\u00e9 ajout\u00e9es \u00e0 la mise en \u0153uvre du param\u00e8tre «PRAGMA integrity_check». Par exemple, les tables sans l'indicateur STRICT ne doivent pas contenir de valeurs num\u00e9riques dans les colonnes de type TEXT et de valeurs textuelles contenant des chiffres dans les colonnes de type NUMERIC. Une v\u00e9rification de l'ordre des lignes a \u00e9galement \u00e9t\u00e9 ajout\u00e9e pour les tables avec l'option «WITHOUT ROWID».\n
Dans l'expression «VACUUM INTO», les param\u00e8tres «PRAGMA synchronous» ont \u00e9t\u00e9 pris en compte.\n
Une option de compilation SQLITE_MAX_ALLOCATION_SIZE a \u00e9t\u00e9 ajout\u00e9e pour limiter la taille des blocs lors de l'allocation de m\u00e9moire.\n
L'algorithme int\u00e9gr\u00e9 de g\u00e9n\u00e9ration de nombres pseudo-al\u00e9atoires dans SQLite a \u00e9t\u00e9 modifi\u00e9, passant d'un chiffrement par flux RC4 \u00e0 Chacha20.\n
L'utilisation d'index avec des noms identiques dans diff\u00e9rents sch\u00e9mas de donn\u00e9es est d\u00e9sormais autoris\u00e9e.\n
Des optimisations de performance ont \u00e9t\u00e9 apport\u00e9es, permettant de r\u00e9duire la charge CPU d'environ 1 % lors d'une activit\u00e9 typique. <\/ul>\n