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 der SQLite-Datenbank-Engine), wurde im April 2009 eingeführt und im November 2010 eingestellt. Sie wurde in WebKit (der Engine von Safari) implementiert und blieb in der Blink-Engine (der Engine von Chrome) aktiv. In Gecko (der Engine von Firefox) wurde sie jedoch nie implementiert und 2019 aus WebKit 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 angezeigt.

Der Bereich „Probleme“ in den Chrome-Entwicklertools mit der Warnung, dass WebSQL in nicht sicheren Kontexten eingestellt wird.

  • [ Fertig.] Der Web SQL-Zugriff in nicht sicheren Kontexten ist seit 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 Testzeitraum für die Einstellung, in dem Web SQL weiterhin verwendet werden konnte, war von Chromium 117 ( 4. Januar 2022) bis Chromium 123 ( 4. Januar 2022) verfügbar. Weitere Informationen zu Tests für eingestellte Funktionen finden Sie unter Erste Schritte mit Tests für Quellen.
  • [ Fertig.] Der Web SQL-Zugriff in allen Kontexten ist ab Chromium 119 nicht mehr verfügbar.

So geht es weiter

Wie bereits in der Einführung erwähnt, sind Technologien der Web Storage API wie localStorage und sessionStorage oder der IndexedDB-Standard in vielen, aber bei weitem nicht in allen Fällen gute Alternativen.

Gründe für die Übergabe des Speicherplatzes an Webentwickler

Mit der Einführung von Wasm können SQL- oder NoSQL-Lösungen im Web eingesetzt 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. Wir haben es durch etwas ersetzt, das von der Open-Source-Community gepflegt wird und als Paket bereitgestellt wird, das beliebig aktualisiert werden kann – ohne dass Fehlerkorrekturen und neue Funktionen direkt in den Browsern 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 eine API, die in die Jahre gekommen ist. Als Kind der späten 2000er-Jahre ist es ein hervorragendes Beispiel für die „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, sehen Sie folgendes Ergebnis:

In den Chrome-Entwicklertools wird im Bereich „Web SQL“ eine Datenbank namens „mydatabase“ mit einer Tabelle namens „rainstorms“ mit den Spalten „mood“ (textuell) und „severity“ (ganzzahl) angezeigt, die einen Eintrag mit der Stimmung „somber“ (düster) und der Schwere „6“ enthält.

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 anerkannten Standard gibt, der SQL auf nützliche Weise unterteilt. Außerdem möchten wir nicht, dass Änderungen an SQLite sich 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 bezüglich der in diesem Beitrag beschriebenen Schritte 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.

Danksagungen

Dieser Artikel wurde von Joe Medley, Ben Morss und Joshua Bell geprüft.