[DOCS-7038] Document new restrictions on index key patterns in 3.4 release notes Created: 25/Jan/16  Updated: 16/Nov/21  Resolved: 28/Oct/16

Status: Closed
Project: Documentation
Component/s: Server
Affects Version/s: None
Fix Version/s: 3.4.0

Type: Task Priority: Critical - P2
Reporter: Max Hirschhorn Assignee: Kay Kim (Inactive)
Resolution: Done Votes: 0
Labels: 3.4, 3.4release
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-11064 Stricter validation of index key patt... Closed
Related
related to SERVER-26659 Only apply stricter index key pattern... Closed
is related to DOCS-9049 3.4: Mention stricter createIndexes v... Closed
Participants:
Days since reply: 7 years, 8 weeks, 3 days ago
Story Points: 1

 Description   

The values in the index key pattern are restricted to

  • numbers > 0 (ascending)
  • numbers < 0 (descending)
  • strings (special index types)

Some specific values that may be of interest for which an error will now be returned:

  • 0
  • NaN
  • undefined and null
  • true and false
  • MinKey and MaxKey

> db.mycoll.createIndex({a: 0})
{
  "ok" : 0,
  "errmsg" : "bad index key pattern { a: 0.0 }: Values in the index key pattern cannot be 0.",
  "code" : 67
}
> db.mycoll.createIndex({a: NaN})
{
  "ok" : 0,
  "errmsg" : "bad index key pattern { a: nan.0 }: Values in the index key pattern cannot be NaN.",
  "code" : 67
}
> db.mycoll.createIndex({a: true})
{
  "ok" : 0,
  "errmsg" : "bad index key pattern { a: true }: Values in index key pattern cannot be of type Bool. Only numbers > 0, numbers < 0, and strings are allowed.",
  "code" : 67
}



 Comments   
Comment by Tim Hawkins [ 18/Dec/16 ]

How do I deal with the situation where I'm restoring a dump from a 3.2 system into an empty new 3.4 system. How can I determine which index is at fault?

Comment by Githook User [ 28/Oct/16 ]

Author:

{u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}

Message: DOCS-9049 DOCS-7038 3.4 index specification validation
Branch: master
https://github.com/mongodb/docs/commit/3d50078e3e6246ae5f6d557aa13946a7a8184924

Comment by David Storch [ 20/Oct/16 ]

As Asya mentions above, SERVER-11064 originally prevented upgrade to 3.4. This is no longer true due to SERVER-26659. Indexes failing the new validation will not cause a 3.4 server to fail startup, and 3.4 secondaries replicating such an index will not fassert(). Therefore, no documentation of this change is required in the upgrade/downgrade instructions. Instead, we just need to note this in the 3.4 compatibility changes page. allison.moore@mongodb.com kay.kim, please let me know if you have any questions about this.

Comment by Asya Kamsky [ 17/Oct/16 ]

Also SERVER-11064 says:

if an index with an invalid key pattern is replicated from
an older version, then newer versions of mongod running in a
mixed-version replica set will fassert()

Which also needs to be called out - and the fassert() error message probably needs to be more clear. So doc note should explain both failing startup and failing replication to 3.4 from older node.

Comment by Asya Kamsky [ 18/Jul/16 ]

Might want to make a specific note about boolean true, that if index attribute was mistakenly added as key field of the index, the solution is to properly move it outside the key definition.

I.e.

key: { a: 1, unique: true}

should become

 key: {a:1}, 
 unique:true 

and not key:{a:1,unique:1}

Generated at Thu Feb 08 07:53:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.