はじめに
FIELDNOTE は、引き継いだ数量文字列のうち、どれが信頼できる数値を意味するか合意しました。その意味を保ち、不確かな将来の書き込みを拒否する、使えるカタログが必要です。バリデーターだけでは既存レコードは整理されず、全値の変換は有用な区別を壊したり数量を作り出したりするおそれがあります。
不確かな元データを隔離し、承認済みのスカラー文字列だけを変換し、実際の MongoDB バリデーターを追加します。通常の有効なキットも作成・更新し、店が業務を続けられることを確かめます。先に「機材レコードを分類して隔離する」を完了してください。そこでのドキュメントポリシー、元データ保全スクリプト、ターミナル・ファイル構文、BSON の区別を使います。この単元は独立しており、新しい混在カタログと、完成した 2 ソースファイルのコピーから始まります。前の環境のファイル・データ・実行中プロセスは不要です。全編を通して Terminal を使い、MongoDB とシェルは準備済みです。所要時間は作者の見積もりです。
/home/labex/project/catalog-desk に repair.js と enforce.js を作ります。提供された policy.js と quarantine.js は確認して保管できます。同等のポリシー・移行実装も同じ契約を満たす必要があります。元の全 ID、無関係なフィールド、元の int/long 型、隔離した不確かな元データ全体、コレクションの同一性、提供ツールを保全します。整数数量に変えてよいのは stock.available の承認文字列だけです。指定どおり KIT-901 を追加し 1 回減らします。拒否された KIT-902 は存在してはいけません。コレクションの削除・再構築、不明数量のゼロ化、元アーカイブの上書き、正当な追加フィールドの禁止はしません。同時書き込みのない逐次作業で、移行全体を覆うトランザクションは提供しません。
承認済みの文字列数量だけを変換する
このステップでは、元データ保全の手順で不確かなレコードを取り除き、合意した文字列表現だけを変換します。Terminal から始め、この単元の準備済み作業領域に入ります。
cd /home/labex/project/catalog-desk
通常のレコードと、新しいカタログの型を確認します。
./catalog show KIT-101
./catalog types
初期データは再び混在しています。KIT-101 は Int32 12、KIT-102 は Long のゼロ、KIT-103/KIT-104 は承認文字列で、KIT-105～KIT-111 は確認が必要です。独立した単元なので、前の単元の移行成功状態をデータベースへコピーしたわけではありません。
リダイレクトなしの cat はファイルを変更せず表示します。先のガイド付き単元から提供されたポリシーと隔離スクリプトを確認します。
cat policy.js
cat quarantine.js
valid は空でない文字列 ID・名前と、0～50 のスカラー BSON int/long を受け入れます。repairable は同じ形で、その範囲の正規十進文字列だけを受け入れます。bad は両方に一致しないものです。隔離スクリプトは BSON 型と完全な元ドキュメントを保ち、対応するアクティブな元レコードを削除する前に既存コピーを検証します。この制御された状況では安全に再実行でき、競合する古いコピーは上書きせず拒否します。
実際の分類を確認し、その保存済みソースをそのまま実行します。
./catalog classify policy.js
./catalog run policy.js quarantine.js
残ったアクティブなレコードと、保全した元データを読みます。
./catalog show
./catalog archive
アクティブなのは KIT-101～KIT-104 だけのはずです。数量の型は順に int、long、string、string のままです。KIT-105～KIT-111 は、欠落・null・配列・Double の区別と仕入先確認用の追加フィールドを含む完全な元データとして隔離されます。まだ数量の推測や変換はしていません。
次に更新パイプラインを保存します。通常の更新ドキュメントは更新演算子を使いますが、以下の配列は各レコードの現在値から変更フィールドを計算する集計ステージです。このパイプラインの $set は指定フィールドを設定し、$toInt: "$stock.available" は現在の入れ子の数量を読み、承認文字列を BSON Int32 に変換します。ドル記号で始まる文字列はフィールド参照で、保存するリテラルではありません。ドット付きの更新先 "stock.available" は、その入れ子のフィールドだけを更新し、stock.rack と他の元フィールドをすべて保ちます。
updateMany は repairable に一致するレコードだけを扱います。既存の有効な int/long は文字列専用セレクターに一致せず、元の型を保ちます。正しいフィルターがなければ、先のレコードが変わった後、変換不能値で止まる場合があります。複数レコードの更新全体はアトミックではありません。onError: 0 や onNull: 0 は数量の捏造になり、タスクに違反します。準備済みの逐次環境には同時書き込みはありません。
前の単元と同じように、REPAIR ヒアドキュメントで完全なファイルをそのまま書きます。
cat > repair.js <<'REPAIR'
printjson(db.equipment.updateMany(
repairable,
[{$set: {"stock.available": {$toInt: "$stock.available"}}}]
));
REPAIR
セレクター名を使えるよう先にポリシーを実行し、保存した更新を続けます。
./catalog run policy.js repair.js
matchedCount: 2 と modifiedCount: 2 を探します。変更件数だけでは保全を確認できないため、実際のドキュメントと型を調べます。
./catalog show
./catalog types
KIT-103 は Int32 12、KIT-104 は Int32 のゼロになりました。KIT-102 は元の long のゼロのままにする必要があります。元の名前、rack、仕入先フィールド、ID はすべて残ります。分類を確認します。
./catalog classify policy.js
アクティブな 4 レコードすべてが valid に属し、他の 2 分類は空のはずです。監査の前に隔離が必要だった理由に注目してください。変換だけでは null、欠落、不確かな値は取り除けません。
承認済み変換を再実行します。
./catalog run policy.js repair.js
承認文字列は残っていないため、両件数はゼロになるはずです。これは冪等な変換であり、あらゆるデータベースエラーが先のレコードまで自動的にロールバックする意味ではありません。構文エラーでは完全なヒアドキュメントを書き直し、再実行します。ファイル名のミスには ls を使って直し、リセットせず既存のデータベースを保ちます。
将来の書き込みを検証し、通常業務を使える状態に保つ
このステップでは、将来のネイティブな MongoDB 書き込みに合意した契約を適用し、店が有効なキットを作成・更新できることを確かめます。Terminal の /home/labex/project/catalog-desk から始めます。
MongoDB の collMod は既存コレクションのオプションを変更します。ここでは、同じ valid セレクターをバリデーターとして付けます。validationLevel: "strict" は挿入と更新を検証し、すでに不正なレコードへの更新も含みます。validationAction: "error" は違反する書き込みを拒否します。moderate は既存の不正レコードへの更新を免除する場合があり、warn は違反を記録しつつ許す場合があります。どちらも、ここで必要な厳格な将来の書き込み契約ではありません。
バリデーターの追加は既存データをさかのぼって整理する操作ではありません。collMod が成功しても、不正な既存レコードは残り得ます。そのため、先に不確かな元データを隔離し、承認文字列だけを変換し、アクティブなカタログを監査しました。コマンドの成功応答はオプション変更の証拠であり、実際に受け入れ・拒否される書き込みは、その効果の証拠です。
ネイティブコマンドを保存します。db.runCommand は現在のコース用データベースで実行し、printjson は実際の応答を表示します。
cat > enforce.js <<'ENFORCE'
printjson(db.runCommand({
collMod: "equipment",
validator: valid,
validationLevel: "strict",
validationAction: "error"
}));
ENFORCE
ポリシーと新ファイルを変更せず実行します。
./catalog run policy.js enforce.js
ok: 1 を確認します。実際のコレクションオプションを読みます。
./catalog status
出力には equipment のバリデーターと、validationLevel: "strict"、validationAction: "error" が含まれるはずです。リーダーは実際のサーバー・シェルのバージョンと選択データベースも報告します。検証成功の結果を代わりに作るものではありません。
通常の書き込み接続で、不確かな将来の挿入を試します。invalid-text は数量が "12 kits" の実際のキットを送ります。接続エラーではなく、非ゼロ終了と Document failed validation を想定してください。
./catalog invalid-text KIT-902
部分的な新レコードが残らないことを確認します。
./catalog show KIT-902
結果は [] のはずです。拒否した書き込みは、不明なテキストをゼロにしたり、代わりの隔離レコードを作ったりしません。将来の不正書き込みは拒否し、隔離レコードは以前の引き継ぎデータを記録します。
正当な新キットを作ります。new ID COUNT は Int32 数量、rack、仕入先フィールドを持つドキュメントを送ります。合意した新 ID KIT-901 と初期数量 4 を使います。
./catalog new KIT-901 4
KIT-901 の挿入が確認されたことを探します。追加の rack・仕入先フィールドは許可される必要があります。use ID COUNT は、十分な数量がある場合だけ利用可能数を減らす、実際の条件付き更新です。1 個使います。
./catalog use KIT-901 1
matchedCount: 1 と modifiedCount: 1 が期待されます。実際の結果を読みます。
./catalog show KIT-901
KIT-901 は name、rack の NEW、supplier の LOCAL を保ち、Int32 の在庫 3 になるはずです。元の整理済み 4 レコードと隔離元データはすべて不変である必要があります。厳格な整数契約でも、既知のゼロ、上限値、既存の long 数量、無関係なフィールド、通常の有効な更新は許します。
成功後に new を再実行しないでください。一意の _id により重複キーエラーになります。さらに減らす意図がなければ use も繰り返しません。保存した修復スクリプトは文字列専用の冪等な述語ですが、通常の在庫使用は毎回意図的に業務状態を変えます。KIT-901 を誤ってもう一度減らしたら、この新キットだけを必要な最終数量に戻すことをタスクで許可します。同じヒアドキュメント構文で小さなネイティブ更新を保存し、確認します。Int32(3) は、値 3 の BSON 32 ビット整数を明示的に作ります。
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
この復旧は新キットだけを対象にし、必要な最終数量 3 にします。引き継いだ元データや隔離元データを上書きする復旧方法ではありません。再利用可能なポリシー・隔離・修復・検証ファイルが、制御された移行全体を表し、実際のカタログは通常の有効な作業が可能なことを示します。
まとめ
他の入れ子のフィールドを置き換えず、すでに有効な数値型も変えずに、承認文字列を変換しました。整理済みカタログを監査し、strict/error 検証で契約を強制し、実際の不正書き込みの拒否を観察し、通常の有効な挿入・更新を完了しました。保存したスクリプトと保全した元データは、制御された再実行可能な保守手順を支えます。全カタログのアトミックな移行や同時書き込みへの安全性は主張しません。
