[SERVER-34609] The db.upgradeCheck() helper silently fails to validate the documents on a collection Created: 23/Apr/18 Updated: 30/Apr/18 Resolved: 30/Apr/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Shell |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Dmitry Ryabtsev | Assignee: | DO NOT USE - Backlog - Platform Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Participants: | |
| Case: | (copied to CRM) |
| Description |
|
I'm not sure if we still maintain these helpers but they often happen to become helpful in cases about Atlas migrations that are failing due to certain limits being violated on the source (e.g. index key size limit). Similar to db.upgradeCheckAllDBs(), db.upgradeCheck() has an extra option that enforces document check (checkDocs). Normally you'd need to call it as db.upgradeCheck(undefined, true); to execute the check on all of the documents in all collections in the database. For the scope of a single collection it would be:
However that does not enforces the document check. The reason is that we don't pass the checkDocs argument into collUpgradeCheck():
It was tested that modifying the collUpgradeCheck() call in the line #158 in upgrade_check.js to have checkDocs fixes the issue. |
| Comments |
| Comment by Gregory McKeon (Inactive) [ 30/Apr/18 ] | |
|
We removed support for these helpers in 3.6, and won't be adding them back to the shell. | |
| Comment by Dmitry Ryabtsev [ 26/Apr/18 ] | |
The impact is that there is no way to check the documents in a single collection. The workaround is to run db.upgradeCheck(undefined, true); - this will check all of the collections in the DB including the one the user wants to check. That may not be optimal however. The alternative is to apply the fix to the upgrade_check.js file and then have it re-loaded in the shell.
Not very frequently but every now and then Atlas users raise a ticket about failed migration due to documents violating the limits. Like in 00491662 where the user runs a source MongoDB deployment with failIndexKeyTooLong set to false (could be b/c of a poor advice that people can on StackOverflow).
It is indeed a single line.
| |
| Comment by Dmitry Ryabtsev [ 24/Apr/18 ] | |
|
Forgot to mention that the code snippet is taken from the 3.4 branch. | |
| Comment by Daniel Pasette (Inactive) [ 23/Apr/18 ] | |
|
these helpers have been removed before 3.6 in |