コレクションにスキーマ検証を追加した後は、いつでも検証ルールを変更できます。たとえば、次のように決定できます。
usersコレクション内のドキュメントには、メール アドレスは不要になりました。passwordフィールドの最小長を 8 文字から 12 文字に増やします。
コレクションのスキーマ検証を変更するには、collMod コマンドを使用し、validator オブジェクトで更新された検証を指定します。
このタスクについて
ルール、検証レベル、検証アクションなど、スキーマ検証のほとんどのコンポーネントを変更できます。
注意
検証レベルを constraint に設定している場合、スキーマ検証ルールを直接変更することはできません。検証ルールを変更するには、strict にダウングレードしてルールを変更してから、constraint にアップグレードし直してください。この手順の詳細については、「制約の検証の指定」を参照してください。
コレクションの検証ルールを更新すると、検証の変更前に挿入されたドキュメントが有効でなくなる可能性があります。MongoDB は、これらの既存の無効なドキュメントを validationLevel に応じて異なる方法で取り扱います。
strictレベルおよびmoderateレベルでは、MongoDBはドキュメントを挿入または更新する際に検証チェックを適用しますが、コレクション内に既に存在するドキュメントを遡及的に検証することはありません。既に無効なドキュメントに対する更新は、更新自体が違反を引き起こさない場合でも失敗します。
constraintレベルでは、そのレベルにアップグレードする際にMongoDBがコレクション全体を検証します。strictにダウングレードしてルールを変更し、その後constraintにアップグレードし直した場合、ドキュメントが新しいルールに一致しないとアップグレードは失敗します。
手順
次の手順では、検証ルールを含むコレクションを作成し、それらのルールを変更します。
検証を使用してコレクションを作成します。
検証ルールを使用して users コレクションを作成します。
db.createCollection("users", { validator: { $jsonSchema: { bsonType: "object", required: [ "username", "password" ], properties: { username: { bsonType: "string", description: "must be a string and is required" }, password: { bsonType: "string", minLength: 8, description: "must be a string at least 8 characters long, and is required" } } } }} )検証スキーマを変更します。
次の collMod コマンドを実行して、password フィールドの minLength を 8 から 12 に変更します。
db.runCommand( { collMod: "users", validator: { $jsonSchema: { bsonType: "object", required: [ "username", "password" ], properties: { username: { bsonType: "string", description: "must be a string and is required" }, password: { bsonType: "string", minLength: 12, description: "must be a string of at least 12 characters, and is required" } } } }} )Tip
collMod コマンドを使用して、検証なしで作成されなかった既存のコレクションに検証を追加することもできます。
結果
次のセクションでは、これらのシナリオでの更新された検証の結果を示します。
無効なドキュメントを挿入した場合。
有効なドキュメントを挿入した場合。
検証ルールの変更により、以前は有効だったドキュメントが無効になった場合。
無効なドキュメントを挿入する
次の操作は、無効なドキュメントを挿入しようとします。最小長が 12 文字であるのに、password フィールドの長さが 10 文字であるため、ドキュメントは無効です。
db.users.insertOne( { "username": "salesAdmin01", "password": "kT9$j4wg#M" })MongoDB は次のエラーを返します。
MongoServerError: Document failed validationAdditional information: { failingDocumentId: ObjectId("62be0adb73c105dde9231299"), details: { operatorName: '$jsonSchema', schemaRulesNotSatisfied: [ { operatorName: 'properties', propertiesNotSatisfied: [ { propertyName: 'password', description: 'must be a string of at least 8 characters, and is required', details: [ { operatorName: 'minLength', specifiedAs: { minLength: 12 }, reason: 'specified string length was not satisfied', consideredValue: 'kT9$j4wg#M' } ] } ] } ] }}有効なドキュメントを挿入する
次の操作は、password フィールドの長さが少なくとも 12 文字である有効なドキュメントを挿入します。
db.users.insertOne( { "username": "salesAdmin01", "password": "8p&SQd7T90$KKx" })以前は有効だったが有効でなくなったドキュメントの処理
スキーマ検証の最初のバージョンでは有効であるものの、2 つ目のバージョンでは有効ではない次のドキュメントを検討してください。
db.users.insertOne( { "username": "salesAdmin02", "password": "i8U60*VyL8" })ドキュメントの password フィールドは 10 文字です。スキーマ検証の最初のバージョンでは、最低 8 文字が必要であり、このドキュメントは有効であることを意味します。ただし、password が 12 文字以上であることを要求するように検証を更新した後、ドキュメントは有効ではなくなります。
スキーマ検証の変更により、以前は有効だったドキュメントが無効になった場合、新しく無効になったドキュメントはコレクション内に残ります。
MongoDB が新しく無効なドキュメントを処理する方法は、スキーマの validationLevel によって異なります。この例のスキーマ検証では、デフォルトの validationLevel である strict が使用されています。つまり、ドキュメントは新しい検証ルールに一致する必要があります。MongoDB はドキュメントが更新されるたびに検証をチェックします。
更新されたスキーマ検証に moderate のvalidationLevelがある場合、このドキュメントは新しい検証ルールに一致する必要はありません。