[DOCS-2465] Comprehensive document about backward-breaking changes in v2.6 Created: 02/Jan/14 Updated: 17/Feb/15 Resolved: 05/Mar/14 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual |
| Affects Version/s: | None |
| Fix Version/s: | v1.3.2 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Richard Kreuter (Inactive) | Assignee: | Kay Kim (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | sprint-rollover | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Days since reply: | 9 years, 50 weeks ago | ||||||||||||||||||||||||||||
| Description |
|
It would be good to have a single document that enumerated the backward-breaking changes that users will face upgrading to v2.6. Broadly, the categories of breakage I can think of include: (1) query engine changes (possibly including tightened semantics of query operators), I propose that this document take the form of an "upgrade preparedness" checklist with maximally precise, step-by-step instructions for how to identify whether the user's application will run afoul of a particular change, and suggestions for what to do about it, whenever possible. |
| Comments |
| Comment by Kay Kim (Inactive) [ 05/Mar/14 ] |
|
first pass finished. Will close and have Dan/Andrew(tall)/Matt open new tickets as specific issues arise. |
| Comment by Githook User [ 05/Mar/14 ] |
|
Author: {u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}Message: |
| Comment by Richard Kreuter (Inactive) [ 02/Jan/14 ] |
|
Link to a proposal for what to do about overly long index keys, |
| Comment by Richard Kreuter (Inactive) [ 02/Jan/14 ] |
|
Changes committed with links to So apps that regularly call ensureIndex may start getting errors where they didn't (but where the old server behavior was dubious, and the likely intent of the ensureIndex call was not being satisfied as a result). For example: suppose an application called for a unique index and there was already a non-unique index on those fields; the application would not get an error, but wouldn't be correct in relying on uniqueness enforcement thereafter. Good luck documenting! |
| Comment by Richard Kreuter (Inactive) [ 02/Jan/14 ] |
|
The issue related to restricting overly long index keys, Note that enforcing the restriction on long index keys has a few obvious consequences (and perhaps non-obvious ones): (1) inserts will fail when the indexed fields are too big, Can't think of other things off the top of my head. |