Introduction
FIELDNOTE a convenu quelles chaînes héritées de quantité représentent des nombres fiables. Il faut maintenant un catalogue utilisable qui conserve ces significations et refuse les écritures futures incertaines. Un validateur seul ne nettoie pas les enregistrements existants, et convertir chaque valeur peut détruire des distinctions utiles ou inventer des quantités.
Vous mettrez les originaux incertains en quarantaine, convertirez uniquement les chaînes scalaires approuvées et ajouterez un véritable validateur MongoDB. Vous créerez et mettrez aussi à jour un kit valide ordinaire pour que le magasin continue à travailler. Terminez d’abord Classer et mettre en quarantaine les enregistrements de matériel : sa politique de documents, son script de préservation des originaux, sa syntaxe terminal/fichiers et ses distinctions BSON sont utilisés ici. Cette unité démarre indépendamment avec un nouveau catalogue mixte et des copies des deux fichiers sources terminés. Aucun fichier, aucune donnée ni aucun processus actif de l’environnement précédent n’est requis. Utilisez Terminal tout au long du TP ; MongoDB et le shell sont prêts. La durée est une estimation de l’auteur.
Créez repair.js et enforce.js dans /home/labex/project/catalog-desk. Vous pouvez examiner et conserver les policy.js et quarantine.js fournis ; des implémentations équivalentes de politique/migration doivent respecter le même contrat. Préservez tous les identifiants d’origine, les champs sans rapport, les types int/long d’origine, les originaux incertains complets en quarantaine, les identités de collection et les outils fournis. Seules les chaînes approuvées dans stock.available peuvent devenir des quantités entières. Ajoutez KIT-901 comme indiqué et décrémentez-le une fois ; KIT-902, refusé, ne doit pas exister. Ne supprimez/reconstruisez pas les collections, ne remplacez pas les quantités inconnues par zéro, n’écrasez pas les originaux archivés et ne durcissez pas les règles au point d’exclure des champs supplémentaires légitimes. Le travail est séquentiel sans écritures concurrentes et ne fournit pas de transaction couvrant toute la migration.
Convertir uniquement les chaînes de quantité approuvées
Dans cette étape, vous retirerez les enregistrements incertains par le processus de préservation des originaux et convertirez uniquement les représentations textuelles convenues. Commencez dans Terminal. Entrez dans l’espace de travail préparé de cette unité :
cd /home/labex/project/catalog-desk
Lisez un enregistrement normal et examinez les types du nouveau catalogue :
./catalog show KIT-101
./catalog types
Les données initiales sont de nouveau mixtes : KIT-101 a Int32 12, KIT-102 a Long zéro, KIT-103/KIT-104 ont des chaînes approuvées et KIT-105 à KIT-111 nécessitent un examen. C’est une unité indépendante ; la migration réussie de l’unité précédente n’a donc pas été copiée dans la base.
cat sans redirection affiche un fichier enregistré au lieu de le changer. Examinez la politique et le script de quarantaine fournis, issus de l’unité guidée précédente :
cat policy.js
cat quarantine.js
Le sélecteur valid accepte des identifiants/noms textuels non vides et des quantités scalaires BSON int/long de 0 à 50. repairable accepte la même structure avec uniquement des chaînes décimales canoniques dans cette plage. bad ne sélectionne ni l’un ni l’autre. Le script de quarantaine préserve les types BSON, conserve les documents d’origine complets et vérifie une copie existante avant de supprimer sa source active correspondante. Il peut être relancé sans risque dans ce scénario contrôlé et refuse une ancienne copie conflictuelle au lieu de l’écraser.
Examinez les véritables groupes, puis exécutez ces sources enregistrées exactes :
./catalog classify policy.js
./catalog run policy.js quarantine.js
Lisez les enregistrements actifs restants et les originaux préservés :
./catalog show
./catalog archive
Seuls KIT-101 à KIT-104 doivent rester actifs. Leurs quantités sont encore respectivement int, long, string et string. KIT-105 à KIT-111 appartiennent à la quarantaine avec leurs originaux complets, y compris les distinctions champ manquant/null/tableau/Double et les champs supplémentaires d’examen fournisseur. Aucune quantité n’a encore été devinée ni convertie.
Enregistrez maintenant un pipeline de mise à jour. Un document de mise à jour ordinaire utilise des opérateurs de mise à jour ; le tableau ci-dessous contient plutôt des étapes d’agrégation qui calculent chaque champ modifié à partir de la valeur actuelle de cet enregistrement. $set dans ce pipeline définit le champ nommé et $toInt: "$stock.available" lit la quantité imbriquée actuelle et convertit la chaîne approuvée en BSON Int32. La chaîne préfixée par un dollar est une référence de champ, pas un texte littéral à stocker. La destination à points "stock.available" ne met à jour que ce champ imbriqué, en conservant stock.rack et chaque autre champ d’origine.
updateMany agit uniquement sur les enregistrements correspondant à repairable. Les quantités int/long déjà valides ne correspondent pas à ce sélecteur limité aux chaînes et gardent leurs types d’origine. Sans filtre correct, une conversion peut s’arrêter sur une valeur non convertible après avoir modifié des enregistrements précédents ; l’ensemble de la mise à jour de plusieurs enregistrements n’est pas atomique. Utiliser onError: 0 ou onNull: 0 inventerait une quantité et enfreindrait cette tâche. Ce scénario séquentiel préparé n’a pas d’écritures concurrentes.
Le here-document REPAIR écrit le fichier complet littéralement, comme dans l’unité précédente :
cat > repair.js <<'REPAIR'
printjson(db.equipment.updateMany(
repairable,
[{$set: {"stock.available": {$toInt: "$stock.available"}}}]
));
REPAIR
Exécutez d’abord la politique pour que les noms de sélecteur soient disponibles, puis votre mise à jour enregistrée :
./catalog run policy.js repair.js
Repérez matchedCount: 2 et modifiedCount: 2. Vérifiez les véritables documents et types, car un nombre de modifications ne suffit pas à établir la préservation :
./catalog show
./catalog types
KIT-103 possède maintenant Int32 12 et KIT-104 Int32 zéro. KIT-102 doit toujours posséder son zéro long d’origine. Tous les noms, emplacements, champs fournisseur et identifiants d’origine restent présents. Examinez la classification restante :
./catalog classify policy.js
Les quatre enregistrements actifs doivent appartenir à valid ; les deux autres groupes doivent être vides. Notez pourquoi la quarantaine était nécessaire avant cet audit : la conversion seule ne retirerait pas les valeurs null, manquantes ou incertaines.
Relancez la conversion approuvée :
./catalog run policy.js repair.js
Les deux compteurs doivent maintenant être nuls, car aucune chaîne approuvée ne reste. C’est une conversion idempotente ; cela ne signifie pas que toute erreur possible de base de données annulerait automatiquement les enregistrements précédents. Si le fichier comporte une erreur de syntaxe, réécrivez le here-document complet et relancez-le. Si un nom de fichier est incorrect, utilisez ls et corrigez-le ; conservez la base existante au lieu de la réinitialiser.
Contrôler les écritures futures et garder le travail ordinaire possible
Dans cette étape, vous appliquerez le contrat de documents accepté aux écritures natives MongoDB futures et prouverez que le magasin peut toujours créer et mettre à jour un kit valide. Commencez dans Terminal, dans /home/labex/project/catalog-desk.
La commande collMod de MongoDB change les options d’une collection existante. Ici, elle attache le même sélecteur valid comme validateur. validationLevel: "strict" valide les insertions et mises à jour, y compris la mise à jour d’un enregistrement déjà invalide. validationAction: "error" rejette une écriture qui enfreint le contrat. moderate peut exempter les mises à jour d’enregistrements déjà invalides ; warn peut autoriser une écriture non conforme tout en la journalisant. Aucun des deux ne correspond au contrat strict d’écritures futures requis ici.
Attacher un validateur ne nettoie pas rétroactivement les données : collMod peut réussir alors que des enregistrements existants invalides restent présents. C’est pourquoi vous avez d’abord mis les originaux incertains en quarantaine, converti uniquement les chaînes approuvées et audité le catalogue actif. Une réponse de commande réussie prouve le changement d’option ; une véritable écriture acceptée/refusée montre ce qu’elle fait.
Enregistrez la commande native. db.runCommand l’exécute sur la base actuelle du cours et printjson affiche sa véritable réponse :
cat > enforce.js <<'ENFORCE'
printjson(db.runCommand({
collMod: "equipment",
validator: valid,
validationLevel: "strict",
validationAction: "error"
}));
ENFORCE
Exécutez la politique et ce nouveau fichier sans les modifier :
./catalog run policy.js enforce.js
Vous devez obtenir ok: 1. Lisez les véritables options de collection :
./catalog status
La sortie doit comprendre le validateur de equipment avec validationLevel: "strict" et validationAction: "error". Ce lecteur indique aussi les véritables versions du serveur/shell et la base sélectionnée ; il ne génère pas pour vous un résultat de validation réussi.
Essayez une insertion future incertaine avec la connexion ordinaire d’écriture. invalid-text soumet un véritable kit dont la quantité est "12 kits". Attendez-vous à un code de sortie non nul et à Document failed validation, pas à une erreur de connexion :
./catalog invalid-text KIT-902
Confirmez qu’aucun nouvel enregistrement partiel n’a été conservé :
./catalog show KIT-902
Le résultat doit être []. L’écriture rejetée n’a pas transformé le texte inconnu en zéro et n’a pas créé d’enregistrement de quarantaine de remplacement. Les écritures futures invalides sont refusées ; les enregistrements de quarantaine documentent les données héritées précédentes.
Créez maintenant un nouveau kit légitime. new ID COUNT soumet un document avec une quantité Int32, un emplacement et des champs fournisseur. Utilisez le nouvel identifiant convenu KIT-901 et une quantité initiale de 4 :
./catalog new KIT-901 4
Repérez l’accusé de réception d’insertion de KIT-901. Ses champs supplémentaires d’emplacement/fournisseur doivent être autorisés. use ID COUNT effectue une véritable mise à jour conditionnelle : il décrémente la quantité disponible uniquement lorsque cet enregistrement possède assez d’unités. Utilisez une unité :
./catalog use KIT-901 1
Vous devez obtenir matchedCount: 1 et modifiedCount: 1. Lisez le véritable résultat :
./catalog show KIT-901
KIT-901 doit conserver son name, son emplacement NEW et son fournisseur LOCAL, avec Int32 3 disponibles. Les quatre enregistrements nettoyés d’origine et tous les originaux de quarantaine doivent rester inchangés. Un contrat strict d’entiers autorise toujours un zéro connu, la borne supérieure inclusive, les quantités long existantes, les champs sans rapport et les mises à jour valides ordinaires.
Ne relancez pas la commande new après sa réussite : l’_id unique produirait une erreur de clé en double. Ne relancez pas use sauf si vous souhaitez une autre décrémentation. Le script de réparation enregistré possède un prédicat idempotent limité aux chaînes ; une action ordinaire d’utilisation du stock change volontairement l’état métier à chaque fois. Si vous décrémentez KIT-901 une nouvelle fois par accident, la tâche du cours autorise à restaurer uniquement ce nouveau kit à la quantité finale requise. Utilisez une petite mise à jour native enregistrée, avec la même syntaxe de here-document, puis examinez-la. Int32(3) construit explicitement un entier BSON sur 32 bits de valeur 3 :
cat > restore-new-kit.js <<'RESTORE'
printjson(db.equipment.updateOne({_id: "KIT-901"}, {$set: {"stock.available": Int32(3)}}));
RESTORE
./catalog run restore-new-kit.js
./catalog show KIT-901
Cette récupération vise uniquement votre nouveau kit et doit laisser la quantité finale requise à 3. Ce n’est pas une méthode de récupération permettant d’écraser les originaux hérités ou en quarantaine. Vos fichiers réutilisables de politique, quarantaine, réparation et validation expriment maintenant la migration contrôlée complète, tandis que le catalogue actif montre que le travail valide normal reste possible.
Résumé
Vous avez converti les chaînes de quantité approuvées sans remplacer les autres champs imbriqués ni modifier les types numériques déjà valides. Vous avez audité le catalogue nettoyé, fait respecter son contrat avec une validation strict/error, observé un véritable refus d’écriture invalide et effectué une insertion/mise à jour valide normale. Les scripts enregistrés et les originaux préservés permettent un processus de maintenance contrôlé et répétable ; ils ne prétendent pas migrer atomiquement tout le catalogue ni garantir la sûreté face aux écritures concurrentes.
