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

XMLWordPrintableJSON

    • Fully Compatible
    • ALL
    • v4.0, v3.6, v3.4
    • 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 }
    • Storage NYC 2018-09-24, Storage NYC 2018-10-08
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      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.

            Assignee:
            Benety Goh
            Reporter:
            David Storch
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: