L'API Web SQL Database, che consente di archiviare i dati in modo strutturato sul computer dell'utente (in base internamente al motore del database SQLite), è stata introdotta nell'aprile 2009 e abbandonata a novembre 2010. Sebbene sia stato implementato in WebKit (alla base di Safari) ed sia rimasto attivo nel motore Blink (che è alla base di Chrome), Gecko (che è alla base di Firefox) non l'ha mai implementata, pertanto WebKit l'ha rimossa nel 2019.
Il World Wide Web Consortium (W3C) incoraggia chi ha bisogno di database web ad adottare tecnologie di API Web Storage come localStorage e sessionStorage o IndexedDB.
Queste tecnologie mostrano i loro punti di forza in termini di archivi chiave/valore e
dati strutturati, ma sono ovviamente anche meno abili, come la mancanza
di un linguaggio di query efficace. C'è un motivo per cui le persone vogliono SQL sul web.
Passaggi per il ritiro e la rimozione di SQL web
- [ Fine.] SQL web è stato deprecato e rimosso per i contesti di terze parti in Chromium 97 ( 4 gennaio 2022).
- [ Fine.] L'accesso SQL web in contesti non sicuri è stato deprecato a partire da Chromium 105 ( 4 gennaio 2022) nel momento in cui è stato visualizzato un messaggio di avviso nel riquadro Problemi di Chrome DevTools.
- [ Fine.] L'accesso SQL web in contesti non sicuri non è più disponibile a partire da Chromium 110 ( 4 gennaio 2022). Un criterio aziendale per continuare a utilizzare questa funzionalità è disponibile da Chromium 110 ( 4 gennaio 2022) a Chromium 123 ( 4 gennaio 2022).
- [ Fine.] L'accesso SQL web in tutti i contesti è deprecato a partire da Chromium 115 ( 4 gennaio 2022) e viene mostrato un messaggio di avviso nel riquadro Problemi di Chrome DevTools.
- [ Fine.] Da Chromium 117 ( 4 gennaio 2022) a Chromium 123 ( 4 gennaio 2022) era disponibile una prova relativa al ritiro per continuare a utilizzare SQL web. Per scoprire di più sulle prove dell'origine, consulta Iniziare a utilizzare le prove dell'origine.
- [ Fine.] L'accesso SQL web in tutti i contesti non è più disponibile in Chromium 119.
Passaggi successivi
Come sottolineato nell'introduzione, le tecnologie
API Web Storage
come
localStorage
e
sessionStorage
o lo standard
IndexedDB
sono buone alternative in molti casi, ma non in tutti i casi.
Ragionamento per lasciare spazio di archiviazione agli sviluppatori web
Con l'avvento di Wasm, le soluzioni SQL o NoSQL possono arrivare sul web. Un esempio è DuckDB-Wasm, un altro è absurd-sql. Sulla base di queste creazioni, riteniamo che la community degli sviluppatori possa eseguire l'iterazione e creare nuove soluzioni di archiviazione in modo più rapido e migliore rispetto ai fornitori di browser.
Non abbiamo intenzione di rimuovere solo SQL web. Infatti, lo abbiamo sostituito con qualcosa che sarà gestito dalla community open source, utilizzato come un pacchetto che può essere aggiornato a piacere, senza l'onere di introdurre correzioni e nuove funzionalità direttamente nei browser. Il nostro obiettivo è permettere agli sviluppatori di portare il proprio database sul web.
Inoltre, ci auguriamo che questo esempio aiuti a prosperare un nuovo ecosistema di database open source. La release degli handle di accesso al file system fornisce infine la nuova primitiva su cui è possibile creare soluzioni di archiviazione personalizzate.
Motivi per il ritiro di SQL web
Problemi di sostenibilità e sicurezza
La specifica SQL web non può essere implementata in modo sostenibile, il che limita l'innovazione e le nuove funzionalità. L'ultima versione dello standard, letteralmente indica "Gli user agent devono implementare il dialetto SQL supportato da Sqlite 3.6.19".
SQLite non è stato inizialmente progettato per eseguire istruzioni SQL dannose, ma implementare SQL web significa che i browser devono fare esattamente questo. La necessità di stare al passo con le correzioni di sicurezza e stabilità impone l'aggiornamento di SQLite in Chromium. Questo entra in un conflitto diretto con il requisito di SQLite che richiede di comportarsi esattamente come SQLite 3.6.19.
Forma API
Anche SQL web è un'API che mostra la sua età. Essendo un bambino della fine degli anni 2000, è un ottimo esempio di "callback inferno", come dimostra il seguente esempio di codice (per gentile concessione di Nolan Lawson). Come puoi vedere, le istruzioni SQL (utilizzando il dialetto SQL SQLite) vengono passate come stringhe ai metodi del database.
openDatabase(
// Name
'mydatabase',
// Version
1,
// Display name
'mydatabase',
// Estimated size
5000000,
// Creation callback
function (db) {
db.transaction(
// Transaction callback
function (tx) {
// Execute SQL statement
tx.executeSql(
// SQL statement
'create table rainstorms (mood text, severity int)',
// Arguments
[],
// Success callback
function () {
// Execute SQL statement
tx.executeSql(
// SQL statement
'insert into rainstorms values (?, ?)',
// Arguments
['somber', 6],
// Success callback
function () {
// Execute SQL statement
tx.executeSql(
// SQL statement
'select * from rainstorms where mood = ?',
// Arguments
['somber'],
// Success callback
function (tx, res) {
// Do something with the result
var row = res.rows.item(0);
console.log(
'rainstorm severity: ' +
row.severity +
', my mood: ' +
row.mood,
);
},
);
},
);
},
);
},
// Error callback
function (err) {
console.log('Transaction failed!: ' + err);
},
// Success callback);
function () {
console.log('Transaction succeeded!');
},
);
},
);
Se esegui questo codice ed esamina la tabella creata con Chrome DevTools, il risultato è:
Mancanza di assistenza da parte dell'implementatore
A parte la forma araba delle API (almeno dal punto di vista attuale), Mozilla aveva molte preoccupazioni relative alla base di SQL web basata su SQLite:
"Non riteniamo che [SQLite] sia la base giusta per un'API esposta a contenuti web generali, non meno di tutte perché non esiste uno standard credibile e ampiamente accettato che sottoponga l'SQL in modo utile. Inoltre, non vogliamo che le modifiche a SQLite influiscano sul web in un secondo momento e non riteniamo che utilizzare le principali release del browser (e uno standard web) in SQLite sia prudente."
Per ulteriori informazioni sulle preoccupazioni di Mozilla, leggi il post del blog dell'ex Mozillan Vladimir Vukićević. Per saperne di più, consulta i minuti del gruppo di lavoro W3C Web Applications (e, se vuoi saperne di più, leggi i log IRC) e gli archivi delle mailing list. Inoltre, il post del blog di Nolan Lawson offre una buona panoramica di quanto è accaduto.
Feedback
In caso di eventuali dubbi sui passaggi per il ritiro comunicati in questo post, utilizza la mailing list di blink-dev. L'iscrizione a questo gruppo è aperta a tutti e chiunque può pubblicare contenuti.
Link correlati
- Voce ChromeStatus: Ritirare e rimuovere WebSQL in contesti di terze parti
- Voce ChromeStatus: Ritirare e rimuovere WebSQL in contesti non sicuri
- Intento di ritiro e rimozione: WebSQL in contesti di terze parti
- Intento di ritiro e rimozione: WebSQL in contesti non sicuri
- Problema di Chromium: Ritirare e rimuovere WebSQL in contesti di terze parti
- Problema di Chromium: Ritira e rimuovi WebSQL in contesti non sicuri
- Problema di Chromium: Ritira e rimuovi WebSQL (Window#openDatabase)
- SQLite Wasm nel browser supportato dal file system privato di origine
Ringraziamenti
Questo articolo è stato letto da Joe Medley, Ben Morss e Joshua Bell.