[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:
Related
related to DOCS-2826 2.6 rel notes cleanup Closed
related to DOCS-2835 remove() without query no longer allowed Closed
related to DOCS-2650 document 2.6 shell helper upgradeCheck() Closed
is related to SERVER-5290 fail to insert docs with fields too l... Closed
is related to SERVER-11178 Create IndexCatalog and remove Catalo... Closed
is related to SERVER-12233 Command to check for over-long index ... Closed
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),
(2) update changes (stricter rules in various places, e.g., no empty string field names),
(3) indexing changes (e.g., erroring rather than storing documents that have overly long index keys, tightening up the rules about index options),
(4) changes to the optimizer and hinting, if any.

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: DOCS-2826 DOCS-2743 DOCS-2650 DOCS-2465 DOCS-2726 backwards compatibility and release notes cleanup
Branch: master
https://github.com/mongodb/docs/commit/94f29def1eda4f0f24d247fa0b3172dabe43d813

Comment by Richard Kreuter (Inactive) [ 02/Jan/14 ]

Link to a proposal for what to do about overly long index keys, SERVER-12233.

Comment by Richard Kreuter (Inactive) [ 02/Jan/14 ]

Changes committed with links to SERVER-11178 have the consequence that calls to ensureIndex with equivalent index key specifications but distinct index options return errors (they were formerly sorta no-ops on the primary, but replicated to secondaries with (some of?) the options.

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, SERVER-5290.

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,
(2) updates will fail when trying to change the indexed fields in the right sorts of ways,
(3) for users with existing data, updates that change other, possibly non-indexed fields will fail whenever those updates cause documents to move (and thereby force index updates),
(4) for users with existing data, migrations will fail whenever a chunk has an existing document that runs afoul of the index key length limit (this might lead to other problems in sharding, e.g., if we always try moving the same chunk and it always fails, chunk balancing in that collection will effectively cease; if we attempt to split chunks in response to the moveChunk failing, then we'll increase the number of chunks without necessity, leading to overly large config dbs later),
(5) for users whose secondaries contain different documents than their primaries (which is a "broken" edge case), index build operations might succeed on a primary and fail later on the secondary.

Can't think of other things off the top of my head.

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