{"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\/it\/blog\/novosti-interneta\/vypusk-subd-sqlite-3-40","title":{"rendered":"Rilascio del DBMS SQLite 3.40","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
\u00c8 stata pubblicata la versione 3.40 di SQLite, un database leggero disponibile come libreria di collegamento. Il codice di SQLite \u00e8 distribuito come dominio pubblico, il che significa che pu\u00f2 essere utilizzato senza restrizioni e gratuitamente per qualsiasi scopo. Il supporto finanziario per gli sviluppatori di SQLite \u00e8 fornito da un consorzio creato appositamente, che include aziende come Adobe, Oracle, Mozilla, Bentley e Bloomberg. <\/p>\n
Principali modifiche: <\/p>\n
\n
\u00c8 stata implementata una funzionalit\u00e0 sperimentale per compilare SQLite in codice intermedio WebAssembly, capace di essere eseguito nei browser web e utile per gestire database da applicazioni web scritte in JavaScript. Gli sviluppatori web hanno a disposizione un'interfaccia orientata agli oggetti ad alto livello per lavorare con i dati in stile sql.js o Node.js, una gestione sopra l'API C di basso livello e un'API basata sul meccanismo dei Web Worker, che consente di creare gestori asincroni eseguiti in thread separati. I dati che le applicazioni web salvano nella versione WASM di SQLite possono essere memorizzati sul lato client utilizzando OPFS (Origin-Private FileSystem) o l'API window.localStorage.\n
\u00c8 stata aggiunta un'estensione di recupero, progettata per il ripristino dei dati da file danneggiati del database. Nell'interfaccia della linea di comando per il recupero viene utilizzato il comando «.recover».\n
Migliorato il funzionamento dello scheduler delle query. Rimosse le limitazioni nell'uso degli indici con tabelle che contano pi\u00f9 di 63 colonne (in precedenza, per le operazioni su colonne il cui numero di sequenza supera 63, l'indicizzazione non veniva applicata). Ottimizzata l'indicizzazione dei valori utilizzati nelle espressioni. Interrotta il caricamento da disco di grandi righe e blob durante l'elaborazione degli operatori NOT NULL e IS NULL. Esclusa la materializzazione delle viste per le quali la scansione completa viene eseguita solo una volta.\n
Nel codice sorgente, invece del tipo «char *» per rappresentare i nomi dei file, \u00e8 stato utilizzato un tipo separato sqlite3_filename.\n
Aggiunta la funzione interna sqlite3_value_encoding().\n
Aggiunta la modalit\u00e0 SQLITE_DBCONFIG_DEFENSIVE, che vieta la modifica della versione dello schema di memorizzazione dei dati.\n
Sono state aggiunte ulteriori verifiche per il parametro \u00abPRAGMA integrity_check\u00bb. Ad esempio, nelle tabelle senza il segno STRICT non devono essere presenti valori numerici nelle colonne di tipo TEXT e valori stringa contenenti numeri nelle colonne di tipo NUMERIC. \u00c8 stata inoltre aggiunta una verifica della correttezza dell\u2019ordine delle righe nelle tabelle con il segno \u00abWITHOUT ROWID\u00bb.\n
Nell'espressione \u00abVACUUM INTO\u00bb sono state considerate le impostazioni \u00abPRAGMA synchronous\u00bb.\n
\u00c8 stata aggiunta l'opzione di compilazione SQLITE_MAX_ALLOCATION_SIZE, che consente di limitare la dimensione dei blocchi durante l'allocazione della memoria.\n
L'algoritmo integrato di SQLite per la generazione di numeri pseudocasuali \u00e8 stato modificato passando dall'uso del cifrario a flusso RC4 a Chacha20.\n
\u00c8 consentito l'uso di indici con nomi identici in schemi di dati diversi.\n
Sono state apportate ottimizzazioni delle prestazioni che hanno permesso di ridurre il carico sulla CPU di circa l'1% durante un'attivit\u00e0 tipica. <\/ul>\n