Die Web SQL Database API, mit der du Daten auf strukturierte Weise auf dem Computer des Nutzers speichern kannst (intern basierend auf dem SQLite-Datenbankmodul), wurde im April 2009 eingeführt und im November 2010 eingestellt. Es wurde zwar in WebKit (das Safari-System) implementiert und blieb in der Blink-Engine (die Chrome treibend) aktiv, Gecko (das für Firefox verwendet) hat diese Funktion jedoch nie implementiert und WebKit hat sie 2019 entfernt.
Das World Wide Web Consortium (W3C) unterstützt diejenigen, die Webdatenbanken benötigen, Web Storage API-Technologien wie localStorage und sessionStorage bzw. IndexedDB einzuführen.
Diese Technologien zeigen ihre Stärken in Bezug auf Schlüssel/Wert-Speicher und strukturierte Daten, haben aber auch Schwächen wie das Fehlen einer starken Abfragesprache. Die Menschen wollen SQL im Web nicht ohne Grund.
Schritte zur Einstellung und Entfernung von Web SQL
- [ Fertig.] Web SQL wurde in Chromium 97 für Kontexte von Drittanbietern eingestellt und am 4. Januar 2022 entfernt.
- [ Fertig.] Der Zugriff auf Web SQL in unsicheren Kontexten wurde mit Chromium 105 am 4. Januar 2022 eingestellt. Zu diesem Zeitpunkt wurde in den Chrome-Entwicklertools eine Warnmeldung angezeigt.
- [ Fertig.] Der Web SQL-Zugriff in unsicheren Kontexten ist ab Chromium 110 (4. Januar 2022) nicht mehr verfügbar. Eine Unternehmensrichtlinie zur weiteren Nutzung der Funktion ist vom Chromium 110 (4. Januar 2022) bis zu Chromium 123 (4. Januar 2022) verfügbar.
- [ Fertig.] Der Zugriff auf Web SQL wurde in allen Kontexten am Chromium 115 ( 4. Januar 2022) eingestellt und im Steuerfeld „Chrome-Entwicklertools“ wird eine Warnmeldung angezeigt.
- [ Wir sind da.] Ein Einstellungstest zur weiteren Nutzung von Web SQL ist vom Chromium 117 (4. Januar 2022) bis zu Chromium 123 (4. Januar 2022) verfügbar. Weitere Informationen zu Einstellungstests finden Sie unter Erste Schritte mit Ursprungstests.
So geht es weiter
Wie in der Einführung erwähnt, sind Technologien der Web Storage API wie localStorage und sessionStorage oder der Standard IndexedDB in vielen, aber bei Weitem nicht allen Fällen gute Alternativen.
Gründe dafür, Webentwicklern Speicher zu überlassen
Mit der Einführung von Wasm können auch SQL- oder NoSQL-Lösungen ins Internet gehen. Ein Beispiel ist DuckDB-Wasm, ein anderes absurd-sql. Aufgrund dieser Entwürfe sind wir der Meinung, dass die Entwickler-Community schneller und besser neue Speicherlösungen iterieren und entwickeln kann als die Browseranbieter.
Wir haben nicht vor, Web SQL einfach zu entfernen. Tatsächlich haben wir sie durch etwas ersetzt, das von der Open-Source-Community verwaltet wird, das als Paket bereitgestellt wird, das jederzeit aktualisiert werden kann, ohne dass Sie Fehlerkorrekturen und neue Funktionen direkt in die Browser einbringen müssen. Unser Ziel ist es, Entwicklern die Möglichkeit zu geben, ihre eigene Datenbank ins Web zu bringen.
Wir hoffen außerdem, dass dieses Beispiel ein neues Ökosystem von Open-Source-Datenbanken unterstützt. Die Veröffentlichung der Zugriffs-Handles für Dateisysteme bietet endlich die neue primitive Methode, auf der benutzerdefinierte Speicherlösungen erstellt 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. Die letzte Version des Standards besagt tatsächlich „User-Agents müssen den von Sqlite 3.6.19 unterstützten SQL-Dialekt implementieren“.
SQLite war ursprünglich nicht für die Ausführung schädlicher SQL-Anweisungen konzipiert, aber bei der Implementierung von Web SQL müssen Browser genau das tun. Da SQLite in Chromium aktualisiert werden muss, um Sicherheits- und Stabilitätskorrekturen auf dem neuesten Stand zu halten, Dies steht in einem direkten Konflikt mit der Anforderung von Web SQL, sich genau wie SQLite 3.6.19 zu verhalten.
API-Form
Web SQL ist auch eine API, die ihr Alter anzeigt. Da Sie ein Kind der späten 2000er-Jahre sind, ist es ein großartiges 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 SQL-Dialekt SQLite) 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 prüfen würden, ist das Ergebnis so:
Fehlende Unterstützung für die Implementierung
Abgesehen von der arkanen API-Form (zumindest aus dem heutigen Standpunkt) hatte Mozilla viele Bedenken hinsichtlich der auf SQLite aufbauenden Web SQL-Abfragen:
„Wir denken nicht, dass [SQLite] die richtige Grundlage für eine API ist, die allgemeinen Webinhalten zugänglich macht. Das liegt vor allem daran, dass es keinen glaubwürdigen, weithin anerkannten Standard gibt, der SQL sinnvoll als Unterteilung in SQL erkennt. Außerdem möchten wir nicht, dass sich Änderungen an SQLite später auf das Web auswirken. Außerdem halten wir die Nutzung großer Browserversionen (und eines Webstandards) für SQLite nicht für vernünftig.“
Informationen zu den Bedenken von Mozilla finden Sie im früheren Blogpost von Mozilla Vladimir Vukićević. Einen tieferen Einblick in die Geschichte Ihrer Arbeit finden Sie in den W3C Web Applications Working Group Minuten (in den IRC-Protokollen) und den Mailinglistenarchiven (in englischer Sprache). Außerdem bietet der Blogpost von Nolan Lawson einen guten Überblick darüber, was passiert ist.
Feedback
Wenn Sie Bedenken bezüglich der in diesem Artikel beschriebenen Schritte zur Einstellung haben, können Sie sich über die Mailingliste blink-dev an uns wenden. Jeder kann Mitglied in dieser Gruppe werden und hat die Berechtigung, Beiträge zu posten.
Weitere Informationen
- ChromeStatus-Eintrag: WebSQL in Drittanbieterkontexten einstellen und entfernen
- ChromeStatus-Eintrag: WebSQL in unsicheren Kontexten verwerfen und entfernen
- Intent to Deprecate and Delete (Verwerfen und Entfernen): WebSQL in Drittanbieterkontexten
- Intent to Deprecate and Remove: WebSQL in unsicheren Kontexten
- Chromium-Problem: WebSQL in Drittanbieterkontexten einstellen und entfernen
- Chromium-Problem: WebSQL in unsicheren Kontexten verwerfen und entfernen
- Chromium-Problem: WebSQL (Window#openDatabase) verwerfen und entfernen
- SQLite-Wasm im Browser, das vom privaten Origin-Dateisystem unterstützt wird
Danksagungen
Dieser Artikel wurde von Joe Medley, Ben Morss und Joshua Bell geprüft.