Die Web SQL Database API, mit der Sie Daten strukturiert auf dem Computer des Nutzers speichern können (intern basierend auf dem SQLite-Datenbankmodul), wurde im April 2009 eingeführt und im November 2010 eingestellt. Sie wurde zwar in WebKit (für Safari) implementiert und blieb in der Blink-Engine (die Chrome unterstützt) aktiv, aber Gecko (für Firefox) hat diese Funktion nie implementiert und WebKit hat sie 2019 entfernt.
Das World Wide Web Consortium (W3C) ermutigt diejenigen, die Webdatenbanken benötigen, Technologien wie die Web Storage API zu verwenden, z. B. localStorage, sessionStorage oder IndexedDB.
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. In den Chrome-Entwicklertools wurde daraufhin eine Warnmeldung im Bereich „Probleme“ angezeigt.
- [ Fertig.] Der Web-SQL-Zugriff in unsicheren Kontexten ist ab Chromium 110 (4. Januar 2022) nicht mehr verfügbar. Eine Unternehmensrichtlinie, mit der die Funktion weiter verwendet werden kann, ist ab Chromium 110 ( 4. Januar 2022) bis Chromium 123 ( 4. Januar 2022) verfügbar.
- [ Fertig.] Der Web SQL-Zugriff in allen Kontexten wurde mit Chromium 115 ( 4. Januar 2022) eingestellt. Im Chrome DevTools-Bereich „Probleme“ wird eine Warnmeldung angezeigt.
- [ Fertig.] Ein Test zur Einstellung für die weitere Nutzung von Web SQL war von Chromium 117 ( 4. Januar 2022) bis Chromium 123 ( 4. Januar 2022) verfügbar. Weitere Informationen zu Einstellungstests 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 Einführung 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 für die Speicherung von Daten durch Webentwickler
Mit der Einführung von Wasm können SQL- oder NoSQL-Lösungen im Web eingeführt werden. Ein Beispiel ist DuckDB-Wasm, ein anderes absurd-sql. Wir sind der Meinung, dass die Entwickler-Community auf der Grundlage dieser Entwicklungen schneller und besser als Browseranbieter neue Speicherlösungen entwickeln kann.
Wir planen nicht nur, Web SQL zu entfernen. Tatsächlich haben wir es durch etwas ersetzt, das von der Open-Source-Community gepflegt wird und als Paket dient, das nach Belieben aktualisiert werden kann, ohne dass direkt in Browsern Fehlerbehebungen und neue Funktionen eingeführt werden müssen. Unser Ziel ist es, Entwicklern die Möglichkeit zu geben, ihre eigene Datenbank ins Web zu stellen.
Außerdem hoffen wir, dass dieses Beispiel dazu beiträgt, ein neues Ökosystem von Open-Source-Datenbanken zu schaffen. Mit der Veröffentlichung von Dateisystemzugriffs-Handles steht endlich ein neues Primitive zur Verfügung, 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 wird ausdrücklich festgelegt, dass User-Agents den von SQLite 3.6.19 unterstützten SQL-Dialekt implementieren müssen.
SQLite war ursprünglich nicht für die Ausführung schädlicher SQL-Anweisungen konzipiert, aber durch die Implementierung von WebSQL müssen Browser genau das tun. Da wir mit Sicherheits- und Stabilitätsfehlern Schritt halten müssen, ist es erforderlich, SQLite in Chromium zu aktualisieren. Dies steht jedoch im direkten Widerspruch zu der Anforderung von Web SQL, sich genau wie SQLite 3.6.19 zu verhalten.
API-Form
Web SQL ist ebenfalls eine API, die ihr Alter anzeigt. Als Kind der späten 2000er-Jahre ist es ein hervorragendes Beispiel für „Callback-Hölle“, wie das folgende Codebeispiel (mit freundlicher Genehmigung von Nolan Lawson) zeigt. Wie Sie sehen, werden die SQL-Anweisungen (unter Verwendung des SQLite-SQL-Dialekts) 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 überprüfen, sieht das Ergebnis so aus:
Mangelnder Support für Implementierer
Abgesehen von der kryptischen API-Form (zumindest aus heutiger Sicht) hatte Mozilla viele Bedenken, dass Web SQL auf SQLite basiert:
„Wir sind der Meinung, dass [SQLite] nicht die richtige Grundlage für eine API ist, die für allgemeine Webinhalte freigegeben ist, nicht zuletzt, weil es keinen glaubwürdigen, allgemein akzeptierten Standard gibt, der SQL auf nützliche Weise unterteilt. Außerdem möchten wir nicht, dass sich Änderungen an SQLite später auf das Web auswirken, und wir sind der Meinung, dass es nicht ratsam ist, wichtige Browserversionen (und einen Webstandard) für SQLite zu nutzen.“
Weitere Informationen zu den Bedenken von Mozilla finden Sie im Blogpost des ehemaligen Mozilla-Mitarbeiters Vladimir Vukićević. Weitere Informationen zur Vorgeschichte finden Sie in den Protokollen der W3C-Arbeitsgruppe für Webanwendungen. Wenn Sie wirklich ins Detail gehen möchten, lesen Sie die IRC-Protokolle und die Archivdaten der Mailingliste. Außerdem bietet Nolan Lawsons Blogpost einen guten Überblick über das, was passiert ist.
Feedback
Wenn Sie Bedenken zu den in diesem Beitrag beschriebenen Schritten zur Einstellung haben, können Sie sich über die Blink-Dev-Mailingliste an uns wenden. 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
- Intent zum Einstellen und Entfernen: 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 vom Origin Private File System
Danksagungen
Dieser Artikel wurde von Joe Medley, Ben Morss und Joshua Bell geprüft.