수량 수정하고 카탈로그 규칙 강제하기

소개

FIELDNOTE는 인계받은 수량 문자열 중 신뢰할 수 있는 숫자를 뜻하는 표현을 합의했습니다. 이제 그 의미를 유지하고 앞으로 불확실한 쓰기를 거부하는 사용 가능한 카탈로그가 필요합니다. 검증기만으로 기존 레코드가 정리되지는 않으며 모든 값을 변환하면 유용한 구분을 없애거나 수량을 만들어 낼 수 있습니다.

불확실한 원본을 격리하고 승인된 스칼라 문자열만 변환한 뒤 실제 MongoDB 검증기를 추가합니다. 매장이 계속 일할 수 있도록 일반적인 유효 키트를 만들고 갱신하기도 합니다. 먼저 장비 레코드 분류하고 격리하기를 완료하세요. 해당 문서 정책, 원본 보존 스크립트, 터미널/파일 구문, BSON 구분을 사용합니다. 이 단원은 새 혼합 카탈로그와 완료된 원본 파일 두 개의 사본으로 독립적으로 시작합니다. 이전 환경의 파일, 데이터, 실행 프로세스는 필요하지 않습니다. 전체 과정에서 Terminal을 사용하세요. MongoDB와 셸은 준비되어 있으며 소요 시간은 저자의 추정입니다.

/home/labex/project/catalog-desk에 repair.js와 enforce.js를 만드세요. 제공된 policy.js와 quarantine.js를 확인하고 유지할 수 있습니다. 동등한 정책/마이그레이션 구현도 같은 계약을 지켜야 합니다. 모든 원래 ID, 무관한 필드, 원래 int/long 자료형, 격리된 완전한 불확실 원본, 컬렉션 식별 정보, 제공된 도구를 보존하세요. stock.available의 승인 문자열만 정수 수량으로 바꿀 수 있습니다. 명시된 KIT-901을 추가하고 한 번 차감하세요. 거부되는 KIT-902는 없어야 합니다. 컬렉션을 삭제/재구성하거나, 알 수 없는 수량을 0으로 바꾸거나, 아카이브 원본을 덮어쓰거나, 적법한 추가 필드를 금지하도록 규칙을 강화하지 마세요. 작업은 동시 쓰기 없이 순차 수행하며 마이그레이션 전체의 트랜잭션을 제공하지 않습니다.

승인된 문자열 수량만 변환하기

이 단계에서는 원본 보존 흐름으로 불확실한 레코드를 제거하고 합의된 문자열 표현만 변환합니다. Terminal에서 시작하세요. 이 단원의 준비된 작업 공간으로 들어가세요:

cd /home/labex/project/catalog-desk

정상 레코드를 읽고 새 카탈로그 자료형을 확인하세요:

./catalog show KIT-101

./catalog types

초기 데이터는 다시 혼합 상태입니다. KIT-101은 Int32 12, KIT-102는 Long 0, 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 here-document는 앞 단원과 같이 전체 파일을 그대로 씁니다:

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 0입니다. KIT-102는 원래 long 0을 유지해야 합니다. 원래 이름, 보관대, 공급업체 필드, ID가 모두 남습니다. 남은 분류를 확인하세요:

./catalog classify policy.js

활성 레코드 네 개가 모두 valid에 있어야 하며 다른 두 그룹은 비어 있어야 합니다. 감사 전에 격리가 필요했던 이유를 확인하세요. 변환만으로는 null, 누락, 불확실한 값을 제거하지 못합니다.

승인 변환을 다시 실행하세요:

./catalog run policy.js repair.js

승인 문자열이 남아 있지 않으므로 두 개수는 이제 모두 0이어야 합니다. 이는 멱등적 변환이며 가능한 모든 데이터베이스 오류가 앞선 레코드를 자동 롤백한다는 뜻이 아닙니다. 파일에 구문 오류가 있으면 전체 here-document를 다시 쓰고 실행하세요. 파일 이름이 틀렸다면 ls로 확인해 수정하고 초기화하지 말고 기존 데이터베이스를 유지하세요.

향후 쓰기를 검증하고 일반 작업 유지하기

이 단계에서는 승인된 문서 계약을 향후 MongoDB 자체 쓰기에 적용하고 매장이 유효한 키트를 계속 생성·갱신할 수 있음을 확인합니다. Terminal의 /home/labex/project/catalog-desk에서 시작하세요.

MongoDB의 collMod 명령은 기존 컬렉션 옵션을 바꿉니다. 여기서는 같은 valid 선택 조건을 검증기로 연결합니다. validationLevel: "strict"는 이미 잘못된 레코드의 갱신을 포함한 삽입과 갱신을 검증합니다. validationAction: "error"는 위반 쓰기를 거부합니다. moderate는 이미 잘못된 레코드의 갱신을 면제할 수 있고 warn은 위반을 기록하면서 쓰기를 허용할 수 있습니다. 어느 쪽도 여기서 요구하는 엄격한 향후 쓰기 계약이 아닙니다.

검증기를 붙이는 것은 기존 데이터의 소급 정리가 아닙니다. 잘못된 기존 레코드가 남아 있어도 collMod가 성공할 수 있습니다. 그래서 먼저 불확실한 원본을 격리하고 승인 문자열만 변환하며 활성 카탈로그를 감사했습니다. 성공한 명령 응답은 옵션이 바뀌었다는 근거이며, 실제 허용/거부 쓰기가 동작의 근거입니다.

MongoDB 자체 명령을 저장하세요. 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

출력에는 validationLevel: "strict"와 validationAction: "error"인 equipment 검증기가 있어야 합니다. 읽기 도구는 실제 서버/셸 버전과 선택된 데이터베이스도 보고하며 성공한 검증 결과를 대신 만들어 주지 않습니다.

일반 쓰기 연결로 불확실한 향후 삽입 하나를 시도하세요. invalid-text는 수량이 "12 kits"인 실제 키트를 제출합니다. 연결 오류가 아니라 0이 아닌 종료 상태와 Document failed validation이 예상됩니다:

./catalog invalid-text KIT-902

부분적인 새 레코드가 남지 않았는지 확인하세요:

./catalog show KIT-902

결과는 []여야 합니다. 거부된 쓰기는 알 수 없는 텍스트를 0으로 바꾸거나 대체 격리 레코드를 만들지 않았습니다. 향후 잘못된 쓰기는 거부하며, 격리 레코드는 앞서 인계받은 데이터를 기록합니다.

이제 적법한 새 키트를 만드세요. new ID COUNT는 Int32 수량, 보관대, 공급업체 필드가 있는 문서를 제출합니다. 합의된 새 ID KIT-901과 초기 수량 4를 사용하세요:

./catalog new KIT-901 4

KIT-901 삽입이 확인되었는지 보세요. 추가 보관대/공급업체 필드도 허용되어야 합니다. use ID COUNT는 해당 레코드의 수량이 충분할 때만 가용 수량을 차감하는 실제 조건부 갱신입니다. 한 개를 사용하세요:

./catalog use KIT-901 1

matchedCount: 1과 modifiedCount: 1이 나와야 합니다. 실제 결과를 읽으세요:

./catalog show KIT-901

KIT-901은 name, 보관대 NEW, 공급업체 LOCAL을 유지하고 가용 수량은 Int32 3이어야 합니다. 원래 정리된 레코드 네 개와 모든 격리 원본은 바뀌지 않아야 합니다. 엄격한 정수 계약도 알려진 0, 상한 포함 경계값, 기존 long 수량, 무관한 필드, 일반적인 유효 갱신을 허용합니다.

성공한 new를 다시 실행하지 마세요. 고유한 _id 때문에 중복 키 오류가 납니다. 추가 차감을 의도하지 않았다면 use도 다시 실행하지 마세요. 저장 수정 스크립트에는 멱등적인 문자열 전용 조건이 있지만 일반 재고 사용 동작은 매번 의도적으로 업무 상태를 바꿉니다. KIT-901을 실수로 한 번 더 차감했다면 과정 작업은 이 새 키트만 필요한 최종 수량으로 복구하도록 허용합니다. 같은 here-document 구문으로 작은 MongoDB 갱신을 저장한 뒤 확인하세요. 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 검증으로 계약을 강제했으며, 실제 잘못된 쓰기 거부를 관찰하고 정상적인 유효 삽입/갱신을 완료했습니다. 저장 스크립트와 보존 원본은 통제되고 반복 가능한 유지보수 흐름을 지원하며, 전체 카탈로그의 원자적 마이그레이션이나 동시 쓰기의 안전성을 주장하지 않습니다.