Die Web SQL Database API, mit der Sie Daten strukturiert auf dem Computer des Nutzers speichern können (intern auf der SQLite-Datenbank-Engine basierend), wurde im April 2009 eingeführt und im November 2010 eingestellt. Die Funktion wurde in WebKit (der Engine von Safari) implementiert und blieb in der Blink-Engine (der Engine von Chrome) aktiv. Gecko (die Engine von Firefox) hat diese Funktion jedoch nie implementiert und WebKit hat sie 2019 entfernt.
Das World Wide Web Consortium (W3C) empfiehlt, dass diejenigen, die Webdatenbanken benötigen, Technologien der Web Storage API wie localStorage und sessionStorage oder IndexedDB verwenden.
Diese Technologien zeigen ihre Stärken bei Schlüssel/Wert-Speichern und strukturierten Daten, haben aber auch Schwächen wie das Fehlen einer leistungsstarken Abfragesprache. Es gibt einen Grund, warum Nutzer SQL im Web verwenden möchten.
Schritte zur Einstellung und Entfernung von Web SQL
- [ Fertig.] Web SQL wurde in Chromium 97 (4. Januar 2022) für Drittanbieterkontexte eingestellt und entfernt.
- [ Fertig.] Der Web SQL-Zugriff in unsicheren Kontexten wurde ab Chromium 105 ( 4. Januar 2022) eingestellt. Zu diesem Zeitpunkt wurde im Bereich „Probleme“ der Chrome-Entwicklertools eine Warnmeldung angezeigt.
- [ Fertig.] Der WebSQL-Zugriff in nicht sicheren Kontexten ist seit Chromium 110 ( 4. Januar 2022) nicht mehr verfügbar. Eine Unternehmensrichtlinie zur weiteren Verwendung der Funktion ist ab Chromium 110 ( 4. Januar 2022) bis Chromium 123 ( 4. Januar 2022) verfügbar.
- [ Fertig.] Der Web SQL-Zugriff in allen Kontexten ist seit Chromium 115 ( 4. Januar 2022) eingestellt. Im Bereich „Probleme“ der Chrome-Entwicklertools wird eine Warnmeldung angezeigt.
- [ Fertig.] Ein Einstellungstestlauf zur weiteren Verwendung von Web SQL war vom 4. Januar 2022 bis zum 4. Januar 2022 verfügbar. Weitere Informationen zu Einstellungen für die Einstellung finden Sie unter Erste Schritte mit Ursprungstests.
- [ Fertig.] Der Web SQL-Zugriff in allen Kontexten ist ab Chromium 119 nicht mehr verfügbar.
So geht es weiter
Wie in der Einleitung erwähnt, sind Web Storage API-Technologien wie localStorage und sessionStorage oder der IndexedDB-Standard in vielen, aber bei Weitem nicht allen Fällen gute Alternativen.
Gründe dafür, dass die Speicherung Webentwicklern überlassen wird
Mit der Einführung von Wasm können SQL- oder NoSQL-Lösungen im Web eingesetzt werden. Ein Beispiel ist DuckDB-Wasm, ein weiteres absurd-sql. Wir sind der Meinung, dass die Entwickler-Community auf Grundlage dieser Kreationen schneller und besser neue Speicherlösungen entwickeln kann als Browseranbieter.
Wir planen nicht, Web SQL einfach zu entfernen. Tatsächlich haben wir es durch etwas ersetzt, das von der Open-Source-Community verwaltet wird und als Paket bereitgestellt wird, das beliebig aktualisiert werden kann, ohne dass Fehlerkorrekturen und neue Funktionen direkt in Browser eingeführt werden müssen. Unser Ziel ist es, Entwicklern die Möglichkeit zu geben, ihre eigene Datenbank ins Web zu bringen.
Wir hoffen, dass dieses Beispiel dazu beitragen wird, dass ein neues Ökosystem von Open-Source-Datenbanken entsteht. Mit der Veröffentlichung von Dateisystemzugriffshandles wird endlich das neue Primitive bereitgestellt, auf dem benutzerdefinierte Speicherlösungen aufgebaut werden können.
Gründe für die Einstellung von Web SQL
Bedenken hinsichtlich Nachhaltigkeit und Sicherheit
Die Web SQL-Spezifikation kann nicht nachhaltig implementiert werden, was Innovationen und neue Funktionen einschränkt. In der letzten Version des Standards heißt es wörtlich: „User-Agents müssen den SQL-Dialekt implementieren, der von SQLite 3.6.19 unterstützt wird.“
SQLite war ursprünglich nicht für die Ausführung schädlicher SQL-Anweisungen konzipiert, aber mit Web SQL müssen Browser genau das tun. Um mit Sicherheits- und Stabilitätskorrekturen Schritt zu halten, muss SQLite in Chromium aktualisiert werden. Dies steht im direkten Widerspruch zur Anforderung von Web SQL, sich genau wie SQLite 3.6.19 zu verhalten.
API-Form
Web SQL ist auch eine API, die in die Jahre gekommen ist. Da es aus den späten 2000er-Jahren stammt, ist es ein gutes Beispiel für „Callback-Hölle“, wie das folgende Codebeispiel (mit freundlicher Genehmigung von Nolan Lawson) zeigt. Wie Sie sehen, werden die SQL-Anweisungen (mit dem SQLite-SQL-Dialekt) als Strings an Datenbankmethoden übergeben.
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!');
},
);
},
);
Wenn Sie diesen Code ausführen und die erstellte Tabelle mit den Chrome-Entwicklertools untersuchen, erhalten Sie folgendes Ergebnis:
Mangelnder Support für Implementierer
Abgesehen von der obskuren API-Form (zumindest aus heutiger Sicht) hatte Mozilla viele Bedenken bezüglich der Verwendung von SQLite für Web SQL:
„Wir sind der Meinung, dass [SQLite] nicht die richtige Grundlage für eine API ist, die für allgemeine Webinhalte verfügbar gemacht wird, nicht zuletzt, weil es keinen glaubwürdigen, weitgehend akzeptierten Standard gibt, der SQL auf sinnvolle Weise einschränkt. Außerdem möchten wir nicht, dass sich Änderungen an SQLite später auf das Web auswirken, und halten es nicht für sinnvoll, wichtige Browser-Releases (und einen Webstandard) für SQLite zu nutzen.“
Die Bedenken von Mozilla werden im Blogpost des ehemaligen Mozilla-Mitarbeiters Vladimir Vukićević beschrieben. Weitere Informationen finden Sie im Protokoll der W3C Web Applications Working Group (und wenn Sie wirklich ins Detail gehen möchten, lesen Sie die IRC-Logs) und die Mailinglistenarchive). Nolan Lawsons Blogbeitrag bietet außerdem einen guten Überblick über die Ereignisse.
Feedback
Wenn Sie irgendwelche Bedenken bezüglich der in diesem Beitrag beschriebenen Schritte zur Einstellung haben, teilen Sie uns dies bitte über die blink-dev-Mailingliste mit. Jeder kann Mitglied dieser Gruppe werden und Beiträge posten.
Weitere Informationen
- ChromeStatus-Eintrag: WebSQL in Drittanbieterkontexten einstellen und entfernen
- ChromeStatus-Eintrag: WebSQL in nicht sicheren Kontexten einstellen und entfernen
- Einstellung und Entfernung geplant: WebSQL in Drittanbieterkontexten
- Einstellung und Entfernung geplant: WebSQL in nicht sicheren Kontexten
- Chromium-Problem: WebSQL in Drittanbieterkontexten einstellen und entfernen
- Chromium-Problem: WebSQL in unsicheren Kontexten einstellen und entfernen
- Chromium-Problem: WebSQL einstellen und entfernen (Window#openDatabase)
- SQLite Wasm im Browser, unterstützt durch das Origin Private File System
Danksagungen
Dieser Artikel wurde von Joe Medley, Ben Morss und Joshua Bell geprüft.