L'API Web SQL Database, che consente di archiviare i dati in modo strutturato sul computer dell'utente (basata internamente sul motore del database SQLite), è stata introdotta nell'aprile 2009 e abbandonata nel novembre 2010. Sebbene fosse implementata in WebKit (che supporta Safari) e rimaneva attiva nel motore Blink (che è alla base di Chrome), Gecko (che supporta Firefox) non ha mai implementato questa funzionalità e WebKit l'ha rimossa nel 2019.
Il World Wide Web Consortium (W3C) incoraggia coloro che hanno bisogno di database web di adottare tecnologie 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 hanno anche dei punti deboli 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.] L'API SQL web è stata deprecata e rimossa per 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) e, nel momento in cui veniva mostrato un messaggio di avviso nel riquadro Problema 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 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 Problema di Chrome DevTools.
- [ Siamo qui.] È disponibile una prova del ritiro per continuare a utilizzare Web SQL da Chromium 117 ( 4 gennaio 2022) a Chromium 123 ( 4 gennaio 2022). Per scoprire di più sulle prove del ritiro, consulta Iniziare a utilizzare le prove dell'origine.
Passaggi successivi
Come indicato nell'introduzione,
tecnologie dell'API Web Storage
come
localStorage
e
sessionStorage
o lo standard
IndexedDB
sono valide alternative in molte, ma di gran lunga non in tutti i casi.
Motivazione 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 e 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 più velocemente e meglio rispetto ai fornitori di browser.
Non prevediamo di rimuovere solo l'SQL web. Infatti, lo abbiamo sostituito con qualcosa che verrà gestito dalla community open source, servito come pacchetto che può essere aggiornato a proprio piacimento, senza l'onere di introdurre correzioni e nuove funzionalità direttamente nei browser. Il nostro obiettivo è consentire agli sviluppatori di portare sul web il loro database.
Inoltre, speriamo che questo esempio aiuti a prosperare un nuovo ecosistema di database open source. Il rilascio degli handle di accesso al file system fornisce infine la nuova funzione primitiva su cui è possibile creare soluzioni di archiviazione personalizzate.
Motivi del 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 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 l'implementazione di SQL web significa che i browser devono farlo esattamente. La necessità di stare al passo con le correzioni di sicurezza e stabilità impone l'aggiornamento di SQLite in Chromium. Questo è in conflitto diretto con il requisito di SQL web di comportarsi esattamente come SQLite 3.6.19.
Forma dell'API
Anche SQL web è un'API che mostra la sua età. Essendo un bambino di fine 2000, è un ottimo esempio di "callback hell", 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 di 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 dovessi eseguire questo codice e controllare la tabella creata con Chrome DevTools, questo è il risultato:
Mancanza di assistenza da parte dell'implementatore
A parte l'arcano forma dell'API (almeno dal punto di vista odierno), Mozilla ha nutrito molte preoccupazioni sulla creazione di SQL web su SQLite:
"Non riteniamo che [SQLite] sia la base giusta per un'API esposta a contenuti web generali, non da ultimo perché non esiste uno standard credibile e ampiamente accettato che sottoponga SQL in modo utile. Inoltre, non vogliamo che le modifiche a SQLite influiscano sul web in un secondo momento e non pensiamo che sia prudente sfruttare le principali release del browser (e uno standard web) per SQLite."
Puoi leggere le preoccupazioni di Mozilla nel ex post del blog di Mozilla Vladimir Vukićević. Per un po' di cronologia, consulta i relativi a W3C Web Applications Working Group (e, se vuoi entrare nei dettagli, leggi i log IRC) e gli archivi delle mailing list. Inoltre, il post del blog di Nolan Lawson fornisce un'ottima panoramica di quello che è successo.
Feedback
In caso di eventuali dubbi sui passaggi per il ritiro comunicati in questo post, contattaci tramite la mailing list blink-dev. La partecipazione a questo gruppo è aperta a tutti e chiunque può pubblicare post.
Link correlati
- Voce ChromeStatus: Depreca e rimuovi WebSQL in contesti di terze parti
- Voce ChromeStatus: Depreca e rimuovi WebSQL in contesti non sicuri
- Intento di deprecazione e rimozione: WebSQL in contesti di terze parti
- Intento di deprecare e rimuovere: WebSQL in contesti non sicuri
- Problema di Chromium: Ritirare e rimuovere WebSQL in contesti di terze parti
- Problema di Chromium: Deprecazione e rimozione di WebSQL in contesti non sicuri
- Problema di Chromium: Depreca e rimuovi WebSQL (Window#openDatabase)
- SQLite Wasm nel browser supportato dal file system privato di origine
Ringraziamenti
Questo articolo è stato esaminato da Joe Medley, Ben Morss e Joshua Bell.