Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-36944

applyOps does not permit unknown field names when creating a v:1 index

    XMLWordPrintable

    Details

    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.0, v3.6, v3.4
    • Steps To Reproduce:
      Hide

      MongoDB Enterprise > db.adminCommand({applyOps: [{op:"i", ns: "test.system.indexes", o: {ns:"test.test", key: {a:1}, name: "a_1", v: 1, unknown: 1}}]})
      {
      	"applied" : 1,
      	"code" : 197,
      	"codeName" : "InvalidIndexSpecificationOption",
      	"errmsg" : "The field 'unknown' is not valid for an index specification. Specification: { ns: \"test.test\", key: { a: 1.0 }, name: \"a_1\", v: 1.0, unknown: 1.0 }",
      	"results" : [
      		false
      	],
      	"ok" : 0
      }
      

      Show
      MongoDB Enterprise > db.adminCommand({applyOps: [{op:"i", ns: "test.system.indexes", o: {ns:"test.test", key: {a:1}, name: "a_1", v: 1, unknown: 1}}]}) { "applied" : 1, "code" : 197, "codeName" : "InvalidIndexSpecificationOption", "errmsg" : "The field 'unknown' is not valid for an index specification. Specification: { ns: \"test.test\", key: { a: 1.0 }, name: \"a_1\", v: 1.0, unknown: 1.0 }", "results" : [ false ], "ok" : 0 }
    • Sprint:
      Storage NYC 2018-09-24, Storage NYC 2018-10-08

      Description

      MongoDB 3.4 introduced validation of index options (SERVER-769). This validation applies to all newly created indexes, regardless of index version. 3.4 also introduced v:2 indexes, so it is illegal for any unknown/unvalidated options to be present in the index catalog for a v:2 index spec. However, old v:1 indexes may exist with unknown options, and oplog entries for creating v:1 indexes with illegal options may exist.

      Therefore, the applyOps command should ignore any unknown options when creating a v:1 index. On the other hand, applyOps should error on unknown options for v:2 indexes. This works correctly for op:"c" createIndexes oplog entries:

      MongoDB Enterprise > db.adminCommand({applyOps: [{op:"c", ui: UUID("a0aff12b-0a98-429b-9f2a-892b57fcdbd5"), ns: "test.$cmd", o: {createIndexes: "c", key: {a:1}, name: "a_1", v:1, unknown: 1}}]})
      { "applied" : 1, "results" : [ true ], "ok" : 1 }
      MongoDB Enterprise > db.adminCommand({applyOps: [{op:"c", ui: UUID("a0aff12b-0a98-429b-9f2a-892b57fcdbd5"), ns: "test.$cmd", o: {createIndexes: "c", key: {b:1}, name: "c_1", v:2, unknown: 1}}]})
      {
      	"applied" : 1,
      	"code" : 197,
      	"codeName" : "InvalidIndexSpecificationOption",
      	"errmsg" : "The field 'unknown' is not valid for an index specification. Specification: { key: { b: 1.0 }, name: \"c_1\", v: 2.0, unknown: 1.0, ns: \"test.c\" }",
      	"results" : [
      		false
      	],
      	"ok" : 0
      }
      

      However, when the oplog entry is an insert into system.indexes, unknown options are rejected regardless of index version:

      MongoDB Enterprise > db.adminCommand({applyOps: [{op:"i", ns: "test.system.indexes", o: {ns:"test.test", key: {a:1}, name: "a_1", unknown: 1, v: 1}}]})
      {
      	"applied" : 1,
      	"code" : 197,
      	"codeName" : "InvalidIndexSpecificationOption",
      	"errmsg" : "The field 'unknown' is not valid for an index specification. Specification: { ns: \"test.test\", key: { a: 1.0 }, name: \"a_1\", unknown: 1.0, v: 1.0 }",
      	"results" : [
      		false
      	],
      	"ok" : 0
      }
      MongoDB Enterprise > db.adminCommand({applyOps: [{op:"i", ns: "test.system.indexes", o: {ns:"test.test", key: {a:1}, name: "a_1", unknown: 1, v: 2}}]})
      {
      	"applied" : 1,
      	"code" : 197,
      	"codeName" : "InvalidIndexSpecificationOption",
      	"errmsg" : "The field 'unknown' is not valid for an index specification. Specification: { collation: { locale: \"simple\" }, ns: \"test.test\", key: { a: 1.0 }, name: \"a_1\", unknown: 1.0, v: 2.0 }",
      	"results" : [
      		false
      	],
      	"ok" : 0
      }
      

      This is not the expected behavior in the v:1 case. It looks like this is due to applyOps's implementation of insert into system.indexes in terms of the DBDirectClient. Support for anything related to system.indexes was recently removed as part of SERVER-36015, but this issue still affects older versions.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: