Einführung
FIELDNOTE hat vereinbart, welche übernommenen Bestandszeichenfolgen verlässliche Zahlen bedeuten. Es benötigt nun einen verwendbaren Katalog, der diese Bedeutungen bewahrt und unklare zukünftige Schreibzugriffe ablehnt. Ein Validator allein bereinigt keine bestehenden Datensätze, und das Umwandeln jedes Werts kann nützliche Unterschiede zerstören oder Bestände erfinden.
Du verschiebst unklare Originale in Quarantäne, wandelst nur freigegebene skalare Zeichenfolgen um und ergänzt einen tatsächlichen MongoDB-Validator. Du erstellst und aktualisierst außerdem ein gewöhnliches gültiges Set, damit das Geschäft weiterarbeiten kann. Schließe zuerst Ausrüstungsdatensätze klassifizieren und in Quarantäne verschieben ab: Seine Dokumentrichtlinie, sein Skript zur Originalbewahrung, Terminal-/Dateisyntax und BSON-Unterschiede werden hier verwendet. Diese Einheit beginnt unabhängig mit einem neuen gemischten Katalog und Kopien der beiden fertigen Quelldateien. Dateien, Daten oder laufende Prozesse aus der früheren Umgebung werden nicht benötigt. Verwende durchgehend Terminal; MongoDB und die Shell sind vorbereitet. Die Dauer ist eine Autorenschätzung.
Erstelle repair.js und enforce.js unter /home/labex/project/catalog-desk. Du darfst die bereitgestellten policy.js und quarantine.js prüfen und behalten; gleichwertige Richtlinien-/Migrationsimplementierungen müssen dieselben Anforderungen erfüllen. Bewahre alle ursprünglichen IDs, unbeteiligten Felder, ursprünglichen int/long-Typen, vollständigen unklaren Originale in Quarantäne, Collection-Identitäten und bereitgestellten Werkzeuge. Nur freigegebene Zeichenfolgen in stock.available dürfen Ganzzahlbestände werden. Ergänze KIT-901 wie angegeben und verringere es einmal; das abgelehnte KIT-902 darf nicht existieren. Entferne/erstelle Collections nicht neu, ersetze unbekannte Bestände nicht durch 0, überschreibe keine Archivoriginale und schließe berechtigte Zusatzfelder nicht durch strengere Regeln aus. Die Arbeit erfolgt sequenziell ohne gleichzeitige Schreiber und bietet keine Transaktion über die gesamte Migration.
Nur freigegebene Bestandszeichenfolgen umwandeln
In diesem Schritt entfernst du unklare Datensätze über den Ablauf mit bewahrtem Original und wandelst nur die vereinbarten Zeichenfolgendarstellungen um. Beginne in Terminal. Wechsle in den vorbereiteten Arbeitsbereich dieser Einheit:
cd /home/labex/project/catalog-desk
Lies einen normalen Datensatz und prüfe die Typen des neuen Katalogs:
./catalog show KIT-101
./catalog types
Die Ausgangsdaten sind erneut gemischt: KIT-101 hat Int32 12, KIT-102 hat Long 0, KIT-103/KIT-104 haben freigegebene Zeichenfolgen, und KIT-105 bis KIT-111 benötigen eine Prüfung. Dies ist eine unabhängige Einheit, daher wurde die erfolgreiche Migration der früheren Einheit nicht in die Datenbank kopiert.
cat ohne Umleitung gibt eine gespeicherte Datei aus, statt sie zu ändern. Prüfe die bereitgestellte Richtlinie und das Quarantäneskript aus der früheren angeleiteten Einheit:
cat policy.js
cat quarantine.js
Der Selektor valid akzeptiert nicht leere Zeichenfolgen-IDs/-Namen und skalare BSON-int/long-Bestände von 0 bis 50. repairable akzeptiert dieselbe Form mit ausschließlich kanonischen Dezimalzeichenfolgen in diesem Bereich. bad wählt keines von beiden. Das Quarantäneskript bewahrt BSON-Typen, behält vollständige Originaldokumente bei und prüft eine bestehende Kopie, bevor es ihre entsprechende aktive Quelle löscht. Es kann in dieser kontrollierten Szene sicher erneut ausgeführt werden und lehnt eine abweichende alte Kopie ab, statt sie zu überschreiben.
Prüfe die tatsächlichen Gruppen und führe dann exakt diese gespeicherten Quellen aus:
./catalog classify policy.js
./catalog run policy.js quarantine.js
Lies die verbleibenden aktiven Datensätze und die bewahrten Originale:
./catalog show
./catalog archive
Nur KIT-101 bis KIT-104 sollten aktiv bleiben. Ihre Bestände sind weiterhin jeweils int, long, string und string. KIT-105 bis KIT-111 gehören mit vollständigen Originalen in Quarantäne, einschließlich der Unterschiede zwischen fehlend/null/Array/Double und der zusätzlichen Felder zur Lieferantenprüfung. Es wurde noch keine Anzahl erraten oder umgewandelt.
Speichere nun eine Update-Pipeline. Ein gewöhnliches Updatedokument verwendet Updateoperatoren; das Array unten enthält stattdessen Aggregationsstufen, die jedes geänderte Feld aus dem aktuellen Wert dieses Datensatzes berechnen. $set in dieser Pipeline setzt das benannte Feld, und $toInt: "$stock.available" liest den aktuellen verschachtelten Bestand und wandelt die freigegebene Zeichenfolge in BSON Int32 um. Die Zeichenfolge mit Dollarpräfix ist ein Feldverweis, kein wörtlich zu speichernder Text. Das gepunktete Ziel "stock.available" aktualisiert nur dieses verschachtelte Feld und bewahrt stock.rack sowie jedes andere ursprüngliche Feld.
updateMany wirkt nur auf Datensätze, die repairable treffen. Bestehende gültige int/long-Bestände passen nicht zu diesem reinen Zeichenfolgenselektor und bewahren ihre ursprünglichen Typen. Ohne korrekten Filter kann eine Umwandlung an einem nicht umwandelbaren Wert anhalten, nachdem frühere Datensätze bereits geändert wurden; die gesamte Aktualisierung mehrerer Datensätze ist nicht atomar. onError: 0 oder onNull: 0 zu verwenden, würde eine Anzahl erfinden und diese Aufgabe verletzen. Diese vorbereitete sequenzielle Szene hat keine gleichzeitigen Schreiber.
Das Here-Dokument REPAIR schreibt die vollständige Datei wie in der früheren Einheit wörtlich:
cat > repair.js <<'REPAIR'
printjson(db.equipment.updateMany(
repairable,
[{$set: {"stock.available": {$toInt: "$stock.available"}}}]
));
REPAIR
Führe die Richtlinie zuerst aus, damit ihre Selektornamen im Gültigkeitsbereich sind, gefolgt von deinem gespeicherten Update:
./catalog run policy.js repair.js
Achte auf matchedCount: 2 und modifiedCount: 2. Prüfe tatsächliche Dokumente und Typen, denn eine Änderungsanzahl allein kann den Erhalt nicht belegen:
./catalog show
./catalog types
KIT-103 hat nun Int32 12 und KIT-104 Int32 0. KIT-102 muss weiterhin seine ursprüngliche long-Ganzzahl 0 haben. Alle ursprünglichen Namen, Fächer, Lieferantenfelder und IDs bleiben erhalten. Prüfe die verbleibende Klassifizierung:
./catalog classify policy.js
Alle vier aktiven Datensätze müssen in valid sein; beide anderen Gruppen sollten leer sein. Beachte, weshalb die Quarantäne vor dieser Prüfung nötig war: Umwandlung allein würde null, fehlende oder unklare Werte nicht entfernen.
Wiederhole die freigegebene Umwandlung:
./catalog run policy.js repair.js
Die beiden Zähler für passende und geänderte Datensätze sollten nun jeweils 0 anzeigen, weil keine freigegebenen Zeichenfolgen bleiben. Die Bestandswerte werden dabei nicht auf 0 gesetzt. Dies ist idempotente Umwandlung; es bedeutet nicht, dass jeder mögliche Datenbankfehler frühere Datensätze automatisch zurückrollen würde. Hat die Datei einen Syntaxfehler, schreibe das vollständige Here-Dokument neu und führe es erneut aus. Ist ein Dateiname falsch, verwende ls und korrigiere ihn; bewahre die bestehende Datenbank, statt sie zurückzusetzen.
Zukünftige Schreibzugriffe absichern und gewöhnliche Arbeit ermöglichen
In diesem Schritt wendest du die akzeptierten Dokumentanforderungen auf zukünftige native MongoDB-Schreibzugriffe an und weist nach, dass das Geschäft weiterhin ein gültiges Set erstellen und aktualisieren kann. Beginne in Terminal unter /home/labex/project/catalog-desk.
MongoDBs Befehl collMod ändert Optionen einer bestehenden Collection. Hier hängt er denselben Selektor valid als Validator an. validationLevel: "strict" validiert Einfügungen und Aktualisierungen, einschließlich einer Aktualisierung eines bereits ungültigen Datensatzes. validationAction: "error" lehnt einen verletzenden Schreibzugriff ab. moderate kann Aktualisierungen bereits ungültiger Datensätze ausnehmen; warn kann einen verletzenden Schreibzugriff zulassen und ihn dabei protokollieren. Keines davon entspricht den hier erforderlichen strengen Anforderungen an künftige Schreibzugriffe.
Einen Validator anzuhängen ist keine rückwirkende Bereinigung: collMod kann erfolgreich sein, während ungültige bestehende Datensätze bleiben. Deshalb hast du zuerst unklare Originale in Quarantäne verschoben, nur freigegebene Zeichenfolgen umgewandelt und den aktiven Katalog geprüft. Eine erfolgreiche Befehlsantwort belegt, dass die Option geändert wurde; ein tatsächlich akzeptierter/abgelehnter Schreibzugriff belegt ihre Wirkung.
Speichere den nativen Befehl. db.runCommand führt ihn auf der aktuellen Kursdatenbank aus, und printjson zeigt seine tatsächliche Antwort:
cat > enforce.js <<'ENFORCE'
printjson(db.runCommand({
collMod: "equipment",
validator: valid,
validationLevel: "strict",
validationAction: "error"
}));
ENFORCE
Führe die Richtlinie und diese neue Datei unverändert aus:
./catalog run policy.js enforce.js
Erwartet wird ok: 1. Lies die tatsächlichen Collection-Optionen:
./catalog status
Die Ausgabe sollte den Validator für equipment mit validationLevel: "strict" und validationAction: "error" enthalten. Dieses Leseprogramm meldet auch tatsächliche Server-/Shell-Versionen und die ausgewählte Datenbank; es erzeugt kein erfolgreiches Validierungsergebnis für dich.
Versuche eine unklare zukünftige Einfügung über die gewöhnliche Schreibverbindung. invalid-text übermittelt ein tatsächliches Set mit dem Bestand "12 kits". Erwarte einen Exit-Status ungleich null und Document failed validation, keinen Verbindungsfehler:
./catalog invalid-text KIT-902
Bestätige, dass kein teilweiser neuer Datensatz erhalten blieb:
./catalog show KIT-902
Das Ergebnis sollte [] sein. Der abgelehnte Schreibzugriff hat den unbekannten Text nicht in 0 verwandelt und keinen Ersatzquarantänedatensatz erstellt. Künftige ungültige Schreibzugriffe werden abgelehnt; die Quarantänedatensätze dokumentieren die früher übernommenen Daten.
Erstelle nun ein berechtigtes neues Set. new ID COUNT übermittelt ein Dokument mit Int32-Bestand, einem Fach und Lieferantenfeldern. Verwende die vereinbarte neue ID KIT-901 und einen Anfangsbestand von 4:
./catalog new KIT-901 4
Achte auf eine bestätigte Einfügung von KIT-901. Seine zusätzlichen Fach-/Lieferantenfelder müssen erlaubt sein. use ID COUNT führt ein tatsächliches bedingtes Update aus: Es verringert die verfügbare Anzahl nur, wenn dieser Datensatz genügend Einheiten hat. Verwende eine Einheit:
./catalog use KIT-901 1
Erwartet werden matchedCount: 1 und modifiedCount: 1. Lies das tatsächliche Ergebnis:
./catalog show KIT-901
KIT-901 sollte sein Feld name, das Fach NEW und den Lieferanten LOCAL bei Int32 3 verfügbaren Einheiten bewahren. Die ursprünglichen vier bereinigten Datensätze und alle Quarantäneoriginale müssen unverändert bleiben. Strenge Ganzzahlanforderungen erlauben weiterhin den bekannten Wert 0, die inklusive Obergrenze, bestehende long-Bestände, unbeteiligte Felder und gewöhnliche gültige Aktualisierungen.
Wiederhole den Befehl new nicht nach Erfolg: Die eindeutige _id würde einen Fehler wegen eines doppelten Schlüssels erzeugen. Wiederhole use nur, wenn du einen weiteren Abzug beabsichtigst. Das gespeicherte Reparaturskript hat ein idempotentes Prädikat nur für Zeichenfolgen; eine gewöhnliche Bestandsnutzung ändert den geschäftlichen Zustand absichtlich bei jedem Aufruf. Verringerst du KIT-901 versehentlich erneut, erlaubt die Kursaufgabe, nur dieses neue Set auf den erforderlichen Endbestand zurückzusetzen. Verwende ein kleines gespeichertes natives Update mit derselben Here-Dokument-Syntax und prüfe es dann. Int32(3) erzeugt ausdrücklich eine BSON-32-Bit-Ganzzahl mit Wert 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
Diese Wiederherstellung zielt nur auf dein neues Set und sollte den erforderlichen Endbestand bei 3 belassen. Sie ist keine Wiederherstellungsmethode zum Überschreiben übernommener oder quarantänisierter Originale. Deine wiederverwendbaren Richtlinien-, Quarantäne-, Reparatur- und Durchsetzungsdateien drücken nun die vollständige kontrollierte Migration aus, während der aktuelle Katalog zeigt, dass normale gültige Arbeit möglich bleibt.
Zusammenfassung
Du hast freigegebene Bestandszeichenfolgen umgewandelt, ohne andere verschachtelte Felder zu ersetzen oder bereits gültige Zahlentypen zu ändern. Du hast den bereinigten Katalog geprüft, seine Anforderungen mit strict/error-Validierung durchgesetzt, eine tatsächliche Ablehnung eines ungültigen Schreibzugriffs beobachtet und ein normales gültiges Einfügen/Aktualisieren abgeschlossen. Die gespeicherten Skripte und bewahrten Originale unterstützen einen kontrollierten wiederholbaren Wartungsablauf; sie beanspruchen weder atomare Migration des gesamten Katalogs noch Sicherheit gegen gleichzeitige Schreiber.
