[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: |
|
||||||||||||||||||||
| 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
Some specific values that may be of interest for which an error will now be returned:
|
| 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: | |||
| Comment by David Storch [ 20/Oct/16 ] | |||
|
As Asya mentions above, | |||
| Comment by Asya Kamsky [ 17/Oct/16 ] | |||
|
Also
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.
and not key:{a:1,unique:1} |