Web SQL einstellen und entfernen

Thomas Steiner

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) unterstützt diejenigen, die Webdatenbanken benötigen, Web Storage API-Technologien wie localStorage und sessionStorage oder IndexedDB zu implementieren. 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 Leute wollen SQL im Web nicht ohne Grund.

Schritte zur Einstellung und Entfernung von Web SQL

  • [ Fertig.] Web SQL wurde in Chromium 97 aus Drittanbieter-Kontexten verworfen und am 4. Januar 2022 entfernt.
  • [ Fertig.] Der Web-SQL-Zugriff in unsicheren Kontexten wurde mit Chromium 105 ( 4. Januar 2022 eingestellt. Zu diesem Zeitpunkt wurde im Problembereich der Chrome-Entwicklertools eine Warnmeldung angezeigt).

Der Bereich „Probleme“ in den Chrome-Entwicklertools mit der Warnung „Web SQL“ in nicht sicheren Kontexten wurde verworfen.

  • [ Fertig.] Der Web-SQL-Zugriff in unsicheren Kontexten ist ab Chromium 110 (4. Januar 2022) nicht mehr verfügbar. Eine Unternehmensrichtlinie, mit der Sie die Funktion weiterhin verwenden können, ist von Chromium 110 (4. Januar 2022) bis Chromium 123 (4. Januar 2022) verfügbar.
  • [ Fertig.] Der Web-SQL-Zugriff wurde mit Chromium 115 (4. Januar 2022) in allen Kontexten eingestellt. Außerdem wird im Bereich „Probleme“ in den Chrome-Entwicklertools 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 ist über Chromium 119 in allen Kontexten 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 dafür, dass Webentwicklern Speicherplatz zur Verfügung gestellt werden

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. Basierend auf diesen Kreationen sind wir der Meinung, dass die Entwickler-Community neue Speicherlösungen schneller und besser als Browseranbieter iterieren und entwickeln kann.

Wir haben nicht vor, Web SQL einfach 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 bringen.

Außerdem hoffen wir, dass dieses Beispiel zum Erfolg eines neuen Systems von Open-Source-Datenbanken beiträgt. Die Version der Zugriffs-Handles für Dateisysteme stellt schließlich die neue Primitive bereit, auf der benutzerdefinierte Speicherlösungen erstellt werden können.

Gründe für die Einstellung von Web SQL

Nachhaltigkeits- und Sicherheitsbedenken

Die Web SQL-Spezifikation kann nicht nachhaltig implementiert werden, was Innovationen und neue Funktionen einschränkt. Die letzte Version des Standards besagt buchstäblich „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. Die Implementierung von Web SQL bedeutet jedoch, dass Browser genau dies tun müssen. Die Notwendigkeit, mit Sicherheits- und Stabilitätsverbesserungen Schritt zu halten, macht es erforderlich, SQLite in Chromium zu aktualisieren. 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 ebenfalls eine API, die ihr Alter anzeigt. Als Kind der späten 2000er-Jahre ist es ein großartiges Beispiel für die Rückrufhö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:

Die Überprüfung des Web SQL-Bereichs in den Chrome-Entwicklertools zeigt eine Datenbank namens mydatabase mit einer Tabelle namens „rainstorms“ mit den Spalten „Stimmung“ (Text) und „Schweregrad“ (Ganzzahl) mit einem Eintrag mit einer Stimmung von „düster“ und einem Schweregrad von sechs.

Fehlende Unterstützung durch den Implementierer

Abgesehen von der arkanen API-Form (zumindest aus heutiger Sicht) hatte Mozilla viele Bedenken bezüglich der auf SQLite basierenden Web SQL-Form:

„Wir sind der Meinung, dass [SQLite] nicht die richtige Grundlage für eine API ist, die allgemeinen Webinhalten zugänglich gemacht wird, nicht zuletzt deshalb, weil es keinen glaubwürdigen, weithin akzeptierten Standard gibt, der SQL auf sinnvolle Weise in Teilmengen einfügt. Außerdem möchten wir nicht, dass sich Änderungen an SQLite später auf das Web auswirken, und halten die Nutzung großer Browser-Releases (und eines Webstandards) in SQLite nicht für sinnvoll.“

Weitere Informationen zu den Bedenken von Mozilla finden Sie im früheren Blogpost von Mozillan Vladimir Vukićević. Weitere Informationen über die Geschichte finden Sie in den W3C Web Applications Working Groupminuten. Wenn Sie wirklich ins Detail gehen möchten, können Sie die IRC-Logs und die Archive der Mailingliste lesen. Darüber hinaus bietet der Blogpost von Nolan Lawson einen guten Überblick darüber, was passiert ist.

Feedback

Falls Sie Anliegen bezüglich der in diesem Beitrag beschriebenen Einstellungsschritte haben, können Sie uns diese über die blink-dev-Mailingliste mitteilen. Jeder kann in dieser Gruppe Mitglied werden und jeder darf posten.

Danksagungen

Dieser Artikel wurde von Joe Medley, Ben Morss und Joshua Bell gelesen.