In SERVER-11064, we made it an error for index key pattern values to be 0, NaN, or non-numeric / non-string types. Existing deployments may have v:0 and v:1 indexes which break the validation rules. As currently implemented, this will prevent upgrade to 3.4 since the validation is applied to all index versions. In order to ensure a smooth upgrade process, we should only apply the new index validation to v:2 indexes, which are new in 3.4. (v:2 indexes support collation and the decimal data type.)
Original description
Related to change made in SERVER-11064 starting up 3.4 on older mongod data directory will fail if it finds one of these technically invalid index definitions. Unfortunately the error message is not very clear as far as what the user must do to fix this:
F INDEX [initandlisten] Found an invalid index { v: 1, key: { softDeleteTime: 1, sparse: true }, name: "softDeleteTime_1_sparse_", ns: "session_cache.session" } on the session_cache.session collection: bad index key pattern { softDeleteTime: 1, sparse: true }: Values in index key pattern cannot be of type bool. Only numbers > 0, numbers < 0, and strings are allowed.
2016-10-17T12:30:14.334-0400 I - [initandlisten] Fatal Assertion 28782
DOCS-7038 is already open to document the changed behavior due to SERVER-11064 but I think it should be linked to directly from the error message on startup - otherwise people will not have any idea what to do and how to fix this.
- is related to
-
SERVER-11064 Stricter validation of index key patterns during index creation and startup
-
- Closed
-
-
DOCS-7038 Document new restrictions on index key patterns in 3.4 release notes
-
- Closed
-
-
-
- Closed
-
- related to
-
-
- Closed
-
-
PHPLIB-447 CreateIndexes should check types of values within keys document
-
- Backlog
-