-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 3.5.13
-
Component/s: Index Maintenance
-
None
-
Fully Compatible
-
ALL
-
v3.4
-
-
Query 2017-10-23
An index created through the applyOps command currently inherits the collection default collation. This behavior is incorrect--replicating such an oplog entry does not cause the index to inherit the collection default collation. This is important, because for indexes with the simple collation, the collation is not specified in the oplog entry, even if the collection has a non-simple default collation.
Note that this bug only applies to oplog entries phrased as insertions into system.indexes, which are only generated when the featureCompatibilityVersion is 3.4. It does not apply to oplog entries of the form:
{ "ts" : Timestamp(1505845525, 1), "t" : NumberLong(1), "h" : NumberLong("8738799795251471513"), "v" : 2, "op" : "c", "ns" : "test.$cmd", "ui" : UUID("03829ff6-acc7-45a3-ab78-9bf4b563ba9c"), "wall" : ISODate("2017-09-19T18:25:25.757Z"), "o" : { "createIndexes" : "c", "v" : 2, "key" : { "a" : 1 }, "name" : "a_1" } }
Indexes created through the applyOps command using this style of oplog entry correctly do not inherit the collection default collation.
Note also that this bug does not apply to 3.4--it only exists in master.
This appears to happen because in the applyOps command, direct inserts into system.indexes cause us to run createIndexes directly on the server. This behavior was introduced in this commit.
- is related to
-
SERVER-31089 createIndex fails with "Index type 'text' does not support collation" but applyops command succeeds for creating the same index
- Closed
- related to
-
SERVER-36944 applyOps does not permit unknown field names when creating a v:1 index
- Closed