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
le tecnologie dell'API Web Storage
come
localStorage
e
sessionStorage,
o
IndexedDB.
Queste tecnologie mostrano i loro punti di forza quando si tratta di archivi chiave/valore e
dati strutturati, ma hanno anche punti deboli riconosciuti, come la mancanza di un
linguaggio di query efficace. Le persone vogliono SQL sul web per un motivo.
Procedura di ritiro e rimozione di Web SQL
- [ Fatto.] SQL web è stato deprecato e rimosso per i contesti di terze parti in Chromium 97 ( 4 gennaio 2022).
- [ Fatto.] L'accesso a Web SQL in contesti non sicuri è stato ritirato a partire da Chromium 105 ( 4 gennaio 2022), quando è stato visualizzato un messaggio di avviso nel riquadro dei problemi di Chrome DevTools.
- [ Fatto.] L'accesso a Web SQL in contesti non sicuri non è più disponibile a partire da Chromium 110 ( 4 gennaio 2022). Un criterio aziendale per continuare a utilizzare la 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 di ritiro, consulta Guida introduttiva alle prove delle origini.
- [ Fatto.] L'accesso a Web SQL in tutti i contesti non è più disponibile da Chromium 119.
Come procedere
Come sottolineato nell'introduzione, le tecnologie dell'API Web Storage come localStorage e sessionStorage o lo standard IndexedDB sono buone alternative in molti casi, ma non in tutti.
Ragionamento per lasciare spazio di archiviazione agli sviluppatori web
Con l'avvento di Wasm, le soluzioni SQL o NoSQL possono essere disponibili sul web. Un esempio è DuckDB-Wasm, un altro è absurd-sql. Sulla base di queste creazioni, riteniamo che la community di sviluppatori possa eseguire l'iterazione e creare nuove soluzioni di archiviazione più velocemente e meglio dei fornitori di browser.
Non prevediamo di rimuovere solo Web SQL. 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 è consentire agli sviluppatori di portare il proprio database sul web.
Inoltre, speriamo che questo esempio aiuti a prosperare un nuovo ecosistema di database open source. Il rilascio di handle di accesso al file system fornisce finalmente il nuovo elemento su cui possono essere costruite soluzioni di archiviazione personalizzate.
Motivi della ritiro di SQL web
Problemi di sostenibilità e sicurezza
La specifica Web SQL non può essere implementata in modo sostenibile, il che limita l'innovazione e le nuove funzionalità. L'ultima versione dello standard afferma letteralmente "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á richiede l'aggiornamento di SQLite in Chromium. Ciò è in diretto contrattempo con il requisito di Web SQL di comportarsi esattamente come SQLite 3.6.19.
Forma API
Anche SQL web è un'API che mostra la sua età. Essendo nato alla fine degli anni 2000, è un ottimo esempio di "inferno di callback", come dimostra il seguente codice di esempio (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 e esamini la tabella creata con Chrome DevTools, il risultato è il seguente:
Mancanza di assistenza per gli implementatori
A parte la forma arcana dell'API (almeno dal punto di vista attuale), Mozilla aveva molti dubbi sul fatto che Web SQL fosse basato su SQLite:
"Non riteniamo che [SQLite] sia la base giusta per un'API esposta ai contenuti web generali, non ultimo perché non esiste uno standard credibile e ampiamente accettato che sottoinserisca SQL in modo utile. Inoltre, non vogliamo che le modifiche a SQLite influiscano in un secondo momento sul web e non riteniamo prudente utilizzare le release dei principali browser (e uno standard web) per SQLite."
Puoi leggere i dubbi di Mozilla nel post del blog dell'ex Mozilla Vladimir Vukićević. Per ulteriori informazioni storiche, consulta i verbali del gruppo di lavoro W3C per le applicazioni web (e, se vuoi davvero entrare nei dettagli, leggi i log IRC) e gli archivi della mailing list. Inoltre, il post del blog di Nolan Lawson fornisce una buona panoramica di cosa è successo.
Feedback
Se hai qualsiasi dubbio sui passaggi di ritiro comunicati in questo post, non esitare a contattarci sulla mailing list blink-dev. L'iscrizione a questo gruppo è aperta a tutti e chiunque può pubblicare.
Link correlati
- Voce di ChromeStatus: Ritiro e rimozione di WebSQL in contesti di terze parti
- Voce di ChromeStatus: Ritiro e rimozione di WebSQL in contesti non sicuri
- Intenzione di ritirare e rimuovere: Utilizzo di 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: Ritiro e rimozione di WebSQL in contesti non sicuri
- Problema di Chromium: Ritira e rimuovi WebSQL (Window#openDatabase)
- SQLite Wasm nel browser supportato dal file system privato di Origin
Ringraziamenti
Questo articolo è stato esaminato da Joe Medley, Ben Morss e Joshua Bell.