-
Type: Task
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: manual
-
Labels:
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.
- is related to
-
SERVER-5290 fail to insert docs with fields too long to index, and fail to create indexes where doc keys are too big
- Closed
-
SERVER-11178 Create IndexCatalog and remove CatalogHacks
- Closed
-
SERVER-12233 Command to check for over-long index keys
- Closed
- related to
-
DOCS-2826 2.6 rel notes cleanup
- Closed
-
DOCS-2835 remove() without query no longer allowed
- Closed
-
DOCS-2650 document 2.6 shell helper upgradeCheck()
- Closed