Von Web SQL zu SQLite Wasm: Leitfaden zur Datenbankmigration

Da SQLite Wasm durch das private Ursprungsdateisystem unterstützt wird, gibt es einen vielseitigen Ersatz für die veraltete Web SQL-Datenbanktechnologie. In diesem Artikel erfahren Sie, wie Sie Ihre Daten von Web SQL zu SQLite Wasm migrieren.

Erforderlicher Hintergrund

Im Beitrag Einstellung und Entfernung von Web SQL wurde die Einstellung der Web SQL-Datenbanktechnologie angekündigt. Die Technologie selbst wird zwar eingestellt, die Anwendungsfälle, für die sie verwendet wird, jedoch nicht. Im nachfolgenden Beitrag SQLite Wasm im Browser, unterstützt vom Origin Private File System werden Ersatztechnologien beschrieben, die auf der SQLite-Datenbank basieren, in Web Assembly kompiliert (Wasm) und vom Origin Private File System unterstützt werden. In diesem Artikel erfahren Sie, wie Sie Datenbanken von Web SQL zu SQLite Wasm migrieren.

Datenbanken migrieren

Die folgenden vier Schritte zeigen die konzeptionelle Idee der Migration einer Web SQL-Datenbank zu SQLite Wasm, wobei die SQLite-Datenbank vom privaten Dateisystem des Ursprungsservers gestützt wird. Dieser Code kann als Grundlage für Ihren eigenen Code dienen, der auf Ihre Anforderungen an die Web SQL-Migration zugeschnitten ist.

Die zu migrierenden Web SQL-Datenbanken

In dieser Migrationsanleitung gehen wir davon aus, dass Sie mindestens eine Web-SQL-Datenbank haben, die für Ihre Anwendung relevante Daten enthält. Im folgenden Screenshot sehen Sie eine Beispieldatenbank namens mydatabase mit einer Tabelle mit Regenstürmen, die Stimmungen den Schweregraden zuordnet. Mit den Chrome-Entwicklertools können Sie WebSQL-Datenbanken zum Debuggen aufrufen, wie im folgenden Screenshot dargestellt.

Eine Web SQL-Datenbank, die in den Chrome DevTools geprüft wird. Die Datenbank heißt „mydatabase“ und enthält eine Tabelle mit drei Spalten: „row_id“, „mood“ und „severity“. Es gibt drei Zeilen mit Beispieldaten.

Web SQL-Datenbank in SQL-Anweisungen übersetzen

Damit die Daten für den Nutzer transparent migriert werden können, also ohne dass er die Migrationsschritte selbst ausführen muss, müssen die Daten in der Datenbank in die ursprünglichen SQL-Anweisungen zurückübersetzt werden, mit denen sie erstellt wurden. Dieses Problem ist schon einmal aufgetreten. Das in diesem Artikel verwendete Migrationsskript mywebsqldump.js basiert auf einer Community-Bibliothek namens websqldump.js, die mit einigen kleinen Anpassungen verwendet wird. Im folgenden Codebeispiel wird der Code gezeigt, der erforderlich ist, um die Web SQL-Datenbank mydatabase in eine Reihe von SQL-Anweisungen umzuwandeln.

websqldump.export({
  database: 'mydatabase',
  version: '1.0',
  success: function(sql) {
    // The SQL statements.
  },
  error: function(err) {
    // Handle the error.
  }
});

Die Ausführung dieses Codes führt zum folgenden SQL-Anweisungsstring.

CREATE TABLE IF NOT EXISTS rainstorms (mood text, severity int);
INSERT INTO rainstorms(mood,severity) VALUES ('somber','6');
INSERT INTO rainstorms(mood,severity) VALUES ('rainy','8');
INSERT INTO rainstorms(mood,severity) VALUES ('stormy','2');

Daten in SQLite Wasm importieren

Jetzt müssen Sie nur noch diese SQL-Befehle im Kontext von SQLite Wasm ausführen. Weitere Informationen zum Einrichten von SQLite Wasm finden Sie im Artikel SQLite Wasm im Browser, der vom privaten Dateisystem des Ursprungsservers unterstützt wird. Das Wesentliche ist noch einmal zu sehen. Dieser Code muss in einem Worker ausgeführt werden, der von der Bibliothek automatisch für Sie erstellt wird. Die erforderlichen HTTP-Header müssen richtig festgelegt sein. Sie können das Paket @sqlite.org/sqlite-wasm über npm installieren.

import { sqlite3Worker1Promiser } from '@sqlite.org/sqlite-wasm';

(async () => {
  try {
    const promiser = await new Promise((resolve) => {
      const _promiser = sqlite3Worker1Promiser({
        onready: () => {
          resolve(_promiser);
        },
      });
    });

    let response;

    response = await promiser('open', {
      filename: 'file:mydatabase.db?vfs=opfs',
    });
    const { dbId } = response;

    const sql = `
      CREATE TABLE IF NOT EXISTS rainstorms (mood text, severity int);
      INSERT INTO rainstorms(mood,severity) VALUES ('somber','6');
      INSERT INTO rainstorms(mood,severity) VALUES ('rainy','8');
      INSERT INTO rainstorms(mood,severity) VALUES ('stormy','2');`
    await promiser('exec', { dbId, sql });

    await promiser('close', { dbId });
  } catch (err) {
    if (!(err instanceof Error)) {
      err = new Error(err.result.message);
    }
    console.error(err.name, err.message);
  }
})();

Prüfen Sie nach Ausführung dieses Codes die importierte Datenbankdatei mit der Chrome-Entwicklertools-Erweiterung OPFS Explorer. Es gibt jetzt zwei Dateien, eine mit der eigentlichen Datenbank und eine mit Journalinformationen. Diese beiden Dateien befinden sich im ursprünglichen privaten Dateisystem. Sie können sie also nur mit der OPFS Explorer-Erweiterung sehen.

Eigenes Ursprungsdateisystem mit den Chrome-Entwicklertools des OPFS Explorer untersuchen Es gibt zwei Dateien, eine mit dem Namen mydatabase.db und eine mit dem Namen mydatabase.db-journal.

Wenn Sie prüfen möchten, ob die importierten Daten mit den ursprünglichen Web SQL-Daten übereinstimmen, klicken Sie auf die Datei mydatabase.db. Die OPFS Explorer-Erweiterung zeigt dann das Dialogfeld Datei speichern an, in dem Sie die Datei im für Nutzer sichtbaren Dateisystem speichern können. Verwenden Sie nach dem Speichern der Datenbankdatei eine SQLite Viewer-App, um die Daten zu untersuchen. Der Project Fugu API Showcase bietet mehrere Apps für die Arbeit mit SQLite im Browser. Mit Sqlime – SQLite Playground können Sie beispielsweise eine SQLite-Datenbankdatei von Ihrer Festplatte öffnen und Abfragen in der Datenbank ausführen. Wie Sie im Screenshot unten sehen, wurde die Tabelle „Regenschauer“ korrekt in SQLite importiert.

Die Datei „mydatabase.db“ im Sqlime SQLite Playground-Tool untersuchen In der App wird die SQL-Abfrage „select star from rainstorms limit 10“ ausgeführt, was zu den drei Zeilen aus den ursprünglichen Beispieldaten aus Web SQL führt.

Web SQL-Speicher freigeben

Es ist zwar (vielleicht überraschend) nicht möglich, eine Web SQL-Datenbank zu löschen, Sie sollten aber trotzdem Speicherplatz freigeben, indem Sie die jetzt veralteten Web SQL-Tabellen löschen, nachdem Sie die Daten in SQLite Wasm migriert haben. Wenn Sie alle Tabellen in einer Web SQL-Datenbank auflisten und sie mit JavaScript löschen möchten, verwenden Sie Code wie im folgenden Snippet:

const dropAllTables = () => {
  try {
    db.transaction(function (tx) {
      tx.executeSql(
        "SELECT name FROM sqlite_master WHERE type='table' AND name !='__WebKitDatabaseInfoTable__'",
        [],
        function (tx, result) {
          const len = result.rows.length;
          const tableNames = [];
          for (let i = 0; i < len; i++) {
            const tableName = result.rows.item(i).name;
            tableNames.push(`'${tableName}'`);
            db.transaction(function (tx) {
              tx.executeSql('DROP TABLE ' + tableName);
            });
          }
          console.log(`Dropped table${tableNames.length > 1 ? 's' : ''}: ${tableNames.join(', ')}.`);
        }
      );
    });
  } catch (err) {
    console.error(err.name, err.message);
  }
};

Mit den Daten nach der Migration arbeiten

Nachdem Sie die Daten migriert haben, arbeiten Sie mit den Daten wie im Codebeispiel für den Einstieg beschrieben. Einzelheiten finden Sie in der Referenz zur SQLite Wasm API. Wir möchten Sie noch einmal daran erinnern, dass Sie von einem Worker aus auf SQLite Wasm zugreifen müssen, wenn Sie das private Ursprungsdateisystem als Speicher-Back-End verwenden.

Jetzt testen

In dieser Demo können Sie eine Web SQL-Datenbank mit Beispieldaten füllen und die Web SQL-Daten dann als SQL-Anweisungen dumpen, die anschließend in SQLite Wasm importiert werden, das vom ursprünglichen privaten Dateisystem unterstützt wird. Zum Schluss befreien Sie Speicherplatz, indem Sie die veralteten Web-SQL-Daten löschen. Die vollständige Implementierung, einschließlich der gepatchten Datei mywebsqldump.js, finden Sie im Quellcode.

Die Demo-App unter web-sql-to-sqlite-wasm.glitch.me

Schlussfolgerungen

Die Migration Ihrer Web SQL-Datenbanken zu SQLite Wasm mit dem privaten Dateisystem des Ursprungs ist für Ihre Nutzer transparent. Sie werden nicht bemerken, dass ihre Daten jetzt im privaten Ursprungsdateisystem einer SQLite-Datenbank und nicht mehr in Web SQL gehostet werden. Insgesamt ist die Migration von Web SQL zu SQLite ein notwendiger Schritt für Webentwickler, die die langfristige Stabilität und Skalierbarkeit ihrer Anwendungen sicherstellen möchten. Der Vorgang erfordert zwar etwas anfänglichen Aufwand, die Vorteile einer robusteren, flexibleren und vor allem zukunftsfähigen Datenbanklösung machen die Investition jedoch lohnenswert.