Introduction
Une équipe d’assistance a besoin d’enregistrements qu’elle peut filtrer et mettre à jour sans perdre l’identifiant de chaque ticket. Cloudflare D1 est une base de données gérée qui stocke les informations liées dans des tables et accepte le SQL, un langage qui décrit les données souhaitées. Une table ressemble à une feuille de calcul : chaque ligne représente un ticket et les colonnes nommées contiennent ses champs.
Avant de commencer ce cours, terminez Connect LabEx to Your Cloudflare Account. Ce laboratoire vous apprend à utiliser le terminal de la VM LabEx, l’autorisation de l’appareil, la confirmation du compte et l’enregistrement de l’ID de compte réel. Si vous accédez directement à ce laboratoire, vous devez d’abord effectuer celui-ci. Vous devez également connaître les bases d’un Worker JavaScript ; aucune connaissance du SQL n’est requise ici.
Vous allez créer une base de données, définir les règles de validité des tickets et distinguer les enregistrements d’entraînement locaux des enregistrements cloud. Ce laboratoire nécessite une base de données D1 temporaire et aucun Worker déployé.
Utilisez votre propre compte d’apprentissage et une VM neuve. La configuration prépare d’abord Node.js 22.22.0, puis exécute npm install pour installer Wrangler 4.131.1 au niveau du projet ainsi que les dépendances d’évaluation dans /home/labex/project/ticket-database. Les versions directes des dépendances sont verrouillées ; l’installation crée son propre fichier lock. La configuration n’effectue aucune connexion au cloud ni opération d’évaluation sur la base de données. Sur une machine personnelle, installez la même version de Wrangler avec npm install --save-dev wrangler@4.131.1 dans votre projet.
Cet exercice utilise de petits enregistrements synthétiques dans les limites des quotas gratuits de D1. L’utilisation existante du compte est prise en compte dans ces quotas. Aucun domaine acheté n’est nécessaire. Conservez cette VM jusqu’à ce que la suppression des ressources et la déconnexion aient toutes deux été vérifiées.
Autoriser cette VM et sélectionner le compte
Dans cette étape, vous connectez ce terminal neuf à votre propre compte d’apprentissage. Une connexion au Dashboard ne suffit pas à autoriser la VM. Les autorisations D1 permettent de créer et de supprimer une base de données, ainsi que de modifier les données avec SQL. Consultez la page de consentement réelle, notamment la section Background Access, avant d’autoriser l’accès.
Ouvrez le projet préparé et vérifiez la version verrouillée de l’interface en ligne de commande :
cd /home/labex/project/ticket-database
npx wrangler --version
La version attendue est 4.131.1. Lancez l’autorisation de l’appareil ; --device affiche un code à saisir dans le navigateur et --browser=false vous permet de choisir vous-même comment ouvrir le navigateur :
npx wrangler login --device --browser=false --scopes account:read user:read d1:write
Ouvrez l’URL affichée dans votre navigateur, saisissez le code actuel, confirmez votre compte d’apprentissage et les autorisations demandées, puis autorisez l’accès. Attendez que le terminal confirme la réussite. Ne collez jamais de mots de passe ou de jetons dans les fichiers du projet.
Cet exemple montre l’autorisation D1 Write ainsi que l’accès au compte et l’accès en arrière-plan requis. Vérifiez votre propre compte d’apprentissage sélectionné avant d’autoriser l’accès.
npx wrangler whoami --json
Vérifiez que loggedIn: true est présent, puis lisez le name et l’id du compte, même si un seul compte est listé. Copiez l’ID voulu dans la configuration ci-dessous. La variable shell suivante utilise 6 octets aléatoires, soit 12 caractères hexadécimaux, afin d’éviter les collisions avec les autres apprenants. Un here-document écrit le JSON situé entre les lignes JSON ; $RUN est développé à l’intérieur.
La barre oblique inverse devant $schema conserve cette clé JSON littérale ; $RUN est toujours remplacé par le nom unique de cette exécution.
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
Remplacez YOUR_ACCOUNT_ID avant d’exécuter le bloc. Gardez ce terminal ouvert afin que RUN reste disponible. name identifie cette exécution ; account_id sélectionne le compte utilisé pour les opérations cloud. Le fichier est un fichier JSON ordinaire, également valide en tant que JSONC. Son écriture ne déploie aucun Worker.
Créer une table locale de tickets
Dans cette étape, vous définissez un schéma : les colonnes et les règles imposées par la base de données. Commencez par créer le conteneur cloud et sa liaison, mais gardez les premières modifications SQL en local.
Créez une base de données cloud temporaire. --binding DB donne au code de l’application un nom court, --update-config enregistre son nom réel et son UUID dans wrangler.jsonc, et --use-remote=false maintient le développement en local :
npx wrangler d1 create "$RUN-db" --binding DB --update-config --use-remote=false
Lisez le nom et l’ID créés, puis examinez la liaison enregistrée :
cat wrangler.jsonc
L’entrée DB doit désigner la base de données de cette exécution. Une liaison est une connexion configurée entre le code et une ressource. Son UUID identifie la base de données cloud, tandis que --local utilise une base de données SQLite distincte dans cette VM. Incluez toujours --local ou --remote dans les commandes SQL.
CREATE TABLE définit une table. INTEGER PRIMARY KEY attribue à chaque ligne un identifiant numérique unique. TEXT stocke des chaînes de caractères. NOT NULL interdit les valeurs manquantes et CHECK rejette les valeurs qui ne respectent pas la règle. DEFAULT fournit une valeur lorsqu’une insertion ne renseigne pas ce champ. Ces contrôles aident à éviter les tickets incomplets.
Écrivez le schéma et deux lignes synthétiques dans un fichier SQL. Le marqueur SQL entre guillemets empêche le shell d’interpréter le contenu. Les instructions SQL se terminent par des points-virgules. INSERT INTO associe les noms des colonnes aux valeurs de chaque ligne :
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
Appliquez le fichier uniquement à la base de données locale :
npx wrangler d1 execute DB --local --file schema.sql
Une commande réussie indique que l’exécution a eu lieu sur la base de données locale. Cela ne prouve pas l’existence d’une table distante. Examinez les définitions des colonnes à l’aide de PRAGMA table_info de SQLite :
npx wrangler d1 execute DB --local --command "PRAGMA table_info(tickets);"
Vous devez trouver id, subject, status et source. Le champ pk identifie la clé primaire, tandis que notnull indique les valeurs obligatoires.
Filtrer, mettre à jour et supprimer des lignes locales
Dans cette étape, vous pratiquez les opérations SQL de base et laissez un marqueur uniquement en local. SELECT choisit les colonnes, FROM désigne une table, WHERE filtre les lignes correspondantes et ORDER BY rend leur ordre prévisible.
npx wrangler d1 execute DB --local --command "SELECT id, subject FROM tickets WHERE status = 'open' ORDER BY id;"
Le résultat doit être le ticket 1, Cannot sign in. Les chaînes SQL utilisent des apostrophes simples à l’intérieur des guillemets doubles de la commande. Ajoutez un ticket d’entraînement local :
npx wrangler d1 execute DB --local --command "INSERT INTO tickets (id, subject, source) VALUES (3, 'Local rehearsal', 'local');"
UPDATE modifie les lignes correspondantes. Lisez toujours la condition WHERE avant l’exécution : si vous l’omettez, toutes les lignes seraient modifiées.
npx wrangler d1 execute DB --local --command "UPDATE tickets SET status = 'closed' WHERE id = 3;"
Essayez un statut invalide pour voir la contrainte protéger les données :
npx wrangler d1 execute DB --local --command "UPDATE tickets SET status = 'lost' WHERE id = 3;"
Cette commande est volontairement vouée à l’échec. Vous devez obtenir un message CHECK constraint failed, et non une erreur d’authentification ou de réseau. La ligne conserve le statut closed. Créez, puis supprimez une ligne temporaire ; DELETE supprime uniquement les lignes qui correspondent à son prédicat :
npx wrangler d1 execute DB --local --command "INSERT INTO tickets (id, subject, source) VALUES (4, 'Temporary', 'local'); DELETE FROM tickets WHERE id = 4;"
Lisez les lignes restantes :
npx wrangler d1 execute DB --local --command "SELECT id, subject, status, source FROM tickets ORDER BY id;"
Vous devez trouver les ID 1, 2 et 3 ; le ticket 3 a le statut closed et la source local. Le ticket 4 est absent. La mise à jour échouée ne doit pas avoir modifié la ligne valide.
Initialiser et examiner la base de données distante
Dans cette étape, vous appliquez le même schéma à la base de données cloud et vérifiez que les modifications locales ne s’y sont pas propagées automatiquement. --remote envoie ces instructions SQL à la base de données correspondant à l’UUID du compte sélectionné.
npx wrangler d1 execute DB --remote --file schema.sql
Si une confirmation est demandée, confirmez uniquement la base de données de ce laboratoire. Ajoutez une ligne distante qui utilise le même ID que la ligne d’entraînement locale, mais des données différentes :
npx wrangler d1 execute DB --remote --command "INSERT INTO tickets (id, subject, source) VALUES (3, 'Cloud inbox', 'remote');"
Lisez explicitement les deux destinations :
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;"
Le ticket distant 3 doit être Cloud inbox, open, remote ; le ticket local 3 doit rester Local rehearsal, closed, local. Cette différence prouve que vous avez choisi la destination voulue.
Dans le Cloudflare Dashboard, sélectionnez le même compte et ouvrez Storage & databases → D1 SQLite Database. Recherchez le nom exact de la base de données de cette exécution et ouvrez sa page de détails. Comparez son ID de base de données avec celui de wrangler.jsonc. Utilisez, si elle est disponible, la vue en lecture seule des tables pour examiner tickets. Ne créez ni ne modifiez de lignes à cet endroit. Les réponses SQL ci-dessus établissent le contenu des lignes ; un nombre retardé dans Metrics ne le fait pas.
Exécutez la vérification de cette étape avant de supprimer la base de données.
Ouvrez Explore Data, puis sélectionnez tickets dans Studio. Consultez les lignes sans les modifier. Le nom aléatoire de la base illustrée appartient à un essai ; le vôtre sera différent. Le ticket 3 est Cloud inbox avec la source remote, tandis que la base locale contient toujours Local rehearsal avec la source local.
Supprimer les ressources temporaires
Dans cette étape, vous supprimez uniquement les ressources de ce laboratoire alors que la VM est encore autorisée. Terminez d’abord toutes les vérifications fonctionnelles. Conservez la configuration jusqu’à la fin de la vérification de suppression.
npx wrangler d1 delete DB
Examinez la demande de confirmation et confirmez uniquement la base de données de cette exécution. Listez ensuite les bases de données :
npx wrangler d1 list --json
Le nom et l’UUID de la base de données que vous avez notés doivent être absents d’une réponse réussie. D’autres ressources peuvent rester présentes. Une erreur d’authentification ou de réseau ne permet pas de conclure : rétablissez l’accès et répétez la lecture avant de continuer. Effectuez la vérification de cette étape pendant que vous êtes encore connecté.
Mettre fin à l’autorisation de cette VM
Dans cette étape, vous mettez fin à l’autorisation seulement après la réussite de la vérification indépendante de la suppression. La déconnexion supprime l’autorisation Wrangler enregistrée sur cette VM ; fermer une VM ne constitue pas un nettoyage cloud.
npx wrangler logout
npx wrangler whoami --json
Vous devez obtenir loggedIn: false. Cette requête non authentifiée peut se terminer avec un code différent de zéro ; cela est attendu uniquement si la réponse structurée indique explicitement que vous êtes déconnecté. Terminez la vérification, puis fermez l’environnement du laboratoire.
Résumé
Vous avez appris à créer une base de données de tickets d’assistance. Vous avez vérifié les résultats observables de la base de données, maintenu explicitement le compte sélectionné et l’état local, puis supprimé les ressources temporaires avant de vous déconnecter.
