Einführung
Ein Support-Team benötigt Datensätze, die es filtern und aktualisieren kann, ohne die Zuordnung zu den einzelnen Tickets zu verlieren. Cloudflare D1 ist eine verwaltete Datenbank, die zusammengehörige Informationen in Tabellen speichert und SQL akzeptiert – eine Sprache, mit der Sie die gewünschten Daten beschreiben. Eine Tabelle ähnelt einer Tabellenkalkulation: Jede Zeile stellt ein Ticket dar, und benannte Spalten enthalten dessen Felder.
Schließen Sie vor Beginn dieses Kurses LabEx mit Ihrem Cloudflare-Konto verbinden ab. Dort lernen Sie das Terminal der LabEx-VM, die Geräteautorisierung, die Kontobestätigung und das Speichern der tatsächlichen Konto-ID kennen. Wenn Sie direkt in die Übungen einsteigen, müssen Sie dieses Lab zuerst absolvieren. Außerdem sollten Sie die Grundlagen eines kleinen JavaScript-Workers verstehen; SQL-Kenntnisse werden hier nicht vorausgesetzt.
Sie erstellen eine Datenbank, definieren Regeln für gültige Tickets und unterscheiden lokale Übungsdatensätze von Cloud-Datensätzen. Für dieses Lab benötigen Sie eine temporäre D1-Datenbank und keinen bereitgestellten Worker.
Verwenden Sie Ihr eigenes Lernkonto und eine neue VM. Die Einrichtung bereitet zunächst Node.js 22.22.0 vor und führt anschließend npm install für das projektlokale Wrangler 4.131.1 sowie alle Abhängigkeiten für die Bewertung unter /home/labex/project/ticket-database aus. Die direkten Abhängigkeitsversionen sind festgelegt; bei der Installation wird eine eigene Lockdatei erstellt. Während der Einrichtung erfolgt weder eine Cloud-Anmeldung noch eine bewertete Datenbankoperation. Installieren Sie auf einem persönlichen Rechner dieselbe Wrangler-Version mit npm install --save-dev wrangler@4.131.1 in Ihrem Projekt.
Diese Übung verwendet kleine synthetische Datensätze innerhalb der kostenlosen D1-Kontingente. Die vorhandene Nutzung Ihres Kontos wird auf diese Kontingente angerechnet. Sie benötigen keine gekaufte Domain. Behalten Sie diese VM, bis sowohl die Ressourcenlöschung als auch die Abmeldung überprüft wurden.
Diese VM autorisieren und das Konto auswählen
In diesem Schritt verbinden Sie dieses neue Terminal mit Ihrem eigenen Lernkonto. Eine Anmeldung im Dashboard autorisiert die VM allein noch nicht. Die D1-Berechtigung erlaubt das Erstellen, Ändern und Löschen von Datenbanken. Prüfen Sie die tatsächliche Einwilligungsseite einschließlich Background Access, bevor Sie die Autorisierung erteilen.
Öffnen Sie das vorbereitete Projekt und prüfen Sie die festgelegte CLI-Version:
cd /home/labex/project/ticket-database
npx wrangler --version
Erwartet wird 4.131.1. Starten Sie die Geräteautorisierung. --device zeigt einen Browser-Code an, und --browser=false überlässt Ihnen die Wahl des Browsers:
npx wrangler login --device --browser=false --scopes account:read user:read d1:write
Öffnen Sie die angezeigte URL in Ihrem Browser, geben Sie den aktuellen Code ein, bestätigen Sie Ihr Lernkonto und die Berechtigungen und erteilen Sie die Autorisierung. Warten Sie, bis das Terminal den Erfolg bestätigt. Fügen Sie niemals Passwörter oder Tokens in Projektdateien ein.
Dieses Beispiel zeigt D1 Write zusammen mit dem Kontozugriff und dem erforderlichen Hintergrundzugriff. Bestätigen Sie vor der Autorisierung, dass das richtige Lernkonto ausgewählt ist.
npx wrangler whoami --json
Prüfen Sie loggedIn: true. Lesen Sie anschließend den Kontonamen name und die Konto-ID id aus, auch wenn nur ein Konto aufgeführt ist. Kopieren Sie die gewünschte ID in die folgende Konfiguration. Die folgende Shell-Variable verwendet 6 zufällige Bytes, also 12 hexadezimale Zeichen, um Kollisionen mit anderen Lernenden zu vermeiden. Ein Here-Document schreibt den JSON-Inhalt zwischen den beiden JSON-Zeilen; $RUN wird darin expandiert.
Der umgekehrte Schrägstrich vor $schema erhält diesen JSON-Schlüssel unverändert; $RUN wird weiterhin durch den eindeutigen Namen dieses Durchlaufs ersetzt.
RUN=labex-c04-d01-$(openssl rand -hex 6)
cat > wrangler.jsonc <<JSON
{
"\$schema": "./node_modules/wrangler/config-schema.json",
"name": "$RUN",
"account_id": "YOUR_ACCOUNT_ID",
"main": "src/index.js",
"compatibility_date": "2026-09-15",
"workers_dev": true,
"preview_urls": false
}
JSON
Ersetzen Sie YOUR_ACCOUNT_ID, bevor Sie den Block ausführen. Lassen Sie dieses Terminal geöffnet, damit RUN verfügbar bleibt. name identifiziert diesen Durchlauf; account_id legt das Konto für Cloud-Operationen fest. Die Datei ist gewöhnliches JSON und damit zugleich gültiges JSONC. Durch das Schreiben dieser Datei wird kein Worker bereitgestellt.
Eine lokale Ticket-Tabelle erstellen
In diesem Schritt definieren Sie ein Schema: die Spalten und Regeln, die die Datenbank erzwingt. Erstellen Sie zunächst den Cloud-Container und sein Binding, halten Sie die ersten SQL-Änderungen jedoch lokal.
Erstellen Sie eine temporäre Cloud-Datenbank. --binding DB gibt dem Anwendungscode einen kurzen Namen, --update-config speichert den tatsächlichen Namen und die UUID in wrangler.jsonc, und --use-remote=false hält die Entwicklung lokal:
npx wrangler d1 create "$RUN-db" --binding DB --update-config --use-remote=false
Lesen Sie den erstellten Namen und die ID und prüfen Sie anschließend das gespeicherte Binding:
cat wrangler.jsonc
Der Eintrag DB muss die Datenbank dieses Durchlaufs benennen. Ein Binding ist eine konfigurierte Verbindung zwischen Code und einer Ressource. Seine UUID identifiziert die Cloud-Datenbank, während --local eine separate SQLite-Datenbank auf dieser VM verwendet. Geben Sie bei SQL-Befehlen immer entweder --local oder --remote an.
CREATE TABLE definiert eine Tabelle. INTEGER PRIMARY KEY gibt jeder Zeile eine eindeutige numerische Identität. TEXT speichert Zeichenketten. NOT NULL verbietet fehlende Werte, und CHECK weist Werte zurück, die außerhalb der Regel liegen. DEFAULT liefert einen Wert, wenn ein INSERT dieses Feld auslässt. Diese Prüfungen helfen, unvollständige Tickets zu verhindern.
Schreiben Sie das Schema und zwei synthetische Zeilen in eine SQL-Datei. Das in Anführungszeichen gesetzte SQL-Markierung verhindert, dass die Shell den Inhalt interpretiert. SQL-Anweisungen enden mit Semikolons. INSERT INTO ordnet die Spaltennamen den Werten in jeder Zeile zu:
cat > schema.sql <<'SQL'
CREATE TABLE tickets (
id INTEGER PRIMARY KEY,
subject TEXT NOT NULL CHECK(length(trim(subject)) > 0),
status TEXT NOT NULL DEFAULT 'open' CHECK(status IN ('open','closed')),
source TEXT NOT NULL
);
INSERT INTO tickets (id, subject, status, source) VALUES
(1, 'Cannot sign in', 'open', 'seed'),
(2, 'Invoice copy', 'closed', 'seed');
SQL
Wenden Sie die Datei ausschließlich auf die lokale Datenbank an:
npx wrangler d1 execute DB --local --file schema.sql
Bei einem erfolgreichen Befehl wird die Ausführung auf der lokalen Datenbank gemeldet. Daraus folgt nicht, dass eine entfernte Tabelle vorhanden ist. Prüfen Sie die Spaltendefinitionen mit SQLite-PRAGMA table_info:
npx wrangler d1 execute DB --local --command "PRAGMA table_info(tickets);"
Erwartet werden id, subject, status und source. Das Feld pk kennzeichnet den Primärschlüssel, während notnull erforderliche Werte angibt.
Lokale Zeilen filtern, aktualisieren und entfernen
In diesem Schritt üben Sie grundlegendes SQL und hinterlassen eine ausschließlich lokale Markierung. SELECT wählt Spalten aus, FROM gibt eine Tabelle an, WHERE filtert passende Zeilen, und ORDER BY sorgt für eine vorhersehbare Reihenfolge.
npx wrangler d1 execute DB --local --command "SELECT id, subject FROM tickets WHERE status = 'open' ORDER BY id;"
Das Ergebnis ist Ticket 1 mit dem Betreff Cannot sign in. SQL-Zeichenketten verwenden einfache Anführungszeichen innerhalb der doppelten Anführungszeichen des Befehls. Fügen Sie ein lokales Übungsticket hinzu:
npx wrangler d1 execute DB --local --command "INSERT INTO tickets (id, subject, source) VALUES (3, 'Local rehearsal', 'local');"
UPDATE ändert passende Zeilen. Lesen Sie vor der Ausführung immer die WHERE-Bedingung: Ohne sie würden Sie jede Zeile ändern.
npx wrangler d1 execute DB --local --command "UPDATE tickets SET status = 'closed' WHERE id = 3;"
Versuchen Sie einen ungültigen Status, um zu sehen, wie die Constraint die Daten schützt:
npx wrangler d1 execute DB --local --command "UPDATE tickets SET status = 'lost' WHERE id = 3;"
Dieser Befehl soll absichtlich fehlschlagen. Erwartet wird die Meldung CHECK constraint failed, nicht ein Authentifizierungs- oder Netzwerkfehler. Die Zeile bleibt closed. Erstellen und löschen Sie anschließend eine temporäre Zeile. DELETE entfernt nur Zeilen, die seinem Prädikat entsprechen:
npx wrangler d1 execute DB --local --command "INSERT INTO tickets (id, subject, source) VALUES (4, 'Temporary', 'local'); DELETE FROM tickets WHERE id = 4;"
Lesen Sie die verbleibenden Zeilen:
npx wrangler d1 execute DB --local --command "SELECT id, subject, status, source FROM tickets ORDER BY id;"
Erwartet werden die IDs 1, 2 und 3. Ticket 3 hat den Status closed und die Quelle local. Ticket 4 ist nicht vorhanden. Das fehlgeschlagene Update darf die gültige Zeile nicht geändert haben.
Die entfernte Datenbank initialisieren und prüfen
In diesem Schritt wenden Sie dasselbe Schema auf die Cloud-Datenbank an und weisen nach, dass lokale Änderungen nicht automatisch dorthin übertragen wurden. --remote sendet diese SQL-Anweisungen an die Datenbank-UUID in Ihrem ausgewählten Konto.
npx wrangler d1 execute DB --remote --file schema.sql
Bestätigen Sie bei einer entsprechenden Nachfrage ausschließlich diese Lab-Datenbank. Fügen Sie eine nur in der entfernten Datenbank vorhandene Zeile mit derselben ID wie die lokale Übungszeile, aber anderen Daten hinzu:
npx wrangler d1 execute DB --remote --command "INSERT INTO tickets (id, subject, source) VALUES (3, 'Cloud inbox', 'remote');"
Lesen Sie beide Ziele ausdrücklich aus:
npx wrangler d1 execute DB --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id;"
npx wrangler d1 execute DB --local --command "SELECT id, subject, status, source FROM tickets ORDER BY id;"
Das entfernte Ticket 3 lautet Cloud inbox, hat den Status open und die Quelle remote. Das lokale Ticket 3 bleibt Local rehearsal, closed, local. Dieser Unterschied beweist, dass Sie das gewünschte Ziel ausgewählt haben.
Wählen Sie im Cloudflare Dashboard dasselbe Konto aus und öffnen Sie Storage & databases → D1 SQLite Database. Suchen Sie den exakten Datenbanknamen dieses Durchlaufs und öffnen Sie dessen Detailseite. Vergleichen Sie die Datenbank-ID mit wrangler.jsonc. Verwenden Sie die schreibgeschützte Tabellenansicht, sofern verfügbar, um tickets zu prüfen. Erstellen oder ändern Sie dort keine Datensätze. Die oben ausgegebenen SQL-Ergebnisse belegen den Inhalt der Zeilen; eine verzögert aktualisierte Metrik zählt dafür nicht.
Führen Sie die Verifikation dieses Schritts aus, bevor Sie die Datenbank löschen.
Öffne Explore Data und wähle in Studio tickets. Prüfe die Zeilen, ohne sie zu bearbeiten. Der zufällige Datenbankname im Beispiel gehört zu einem Testdurchlauf; deiner wird anders sein. Ticket 3 lautet Cloud inbox mit der Quelle remote, während die lokale Datenbank weiterhin Local rehearsal mit der Quelle local enthält.
Temporäre Ressourcen löschen
In diesem Schritt entfernen Sie nur die Ressourcen dieses Labs, solange die VM noch autorisiert ist. Schließen Sie zuerst alle funktionalen Prüfungen ab. Behalten Sie die Konfiguration, bis die Löschung bestätigt wurde.
npx wrangler d1 delete DB
Prüfen Sie die Nachfrage und bestätigen Sie ausschließlich die Datenbank dieses Durchlaufs. Listen Sie anschließend die Datenbanken auf:
npx wrangler d1 list --json
Der aufgezeichnete Datenbankname und die UUID müssen in einer erfolgreichen Antwort fehlen. Andere Ressourcen dürfen weiterhin vorhanden sein. Ein Authentifizierungs- oder Netzwerkfehler ist nicht aussagekräftig: Beheben Sie den Zugriffsfehler und wiederholen Sie die Abfrage, bevor Sie fortfahren. Führen Sie die Verifikation dieses Schritts aus, solange Sie noch angemeldet sind.
Die Autorisierung dieser VM beenden
In diesem Schritt beenden Sie die Autorisierung erst, nachdem die unabhängige Löschprüfung erfolgreich war. Die Abmeldung entfernt die gespeicherte Wrangler-Autorisierung dieser VM; das bloße Schließen einer VM bereinigt keine Cloud-Ressourcen.
npx wrangler logout
npx wrangler whoami --json
Erwartet wird loggedIn: false. Diese nicht authentifizierte Abfrage kann mit einem Status ungleich null beendet werden. Das ist nur dann erwartungsgemäß, wenn die strukturierte Antwort ausdrücklich angibt, dass Sie abgemeldet sind. Schließen Sie nach der Überprüfung die Lab-Umgebung.
Zusammenfassung
Sie haben das Erstellen einer Support-Ticket-Datenbank geübt. Sie haben sichtbare Datenbankergebnisse geprüft, das ausgewählte Konto und den lokalen Zustand eindeutig getrennt gehalten und die temporären Ressourcen vor der Abmeldung entfernt.
