[SERVER-8422] Log/getLastError/profile output reports nupdated:1 even if no change Created: 31/Jan/13 Updated: 10/Dec/14 Resolved: 04/Mar/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Write Ops |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | daniel.roberts@10gen.com | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | getLastError, modifiers, updates | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Repro:
|
| Comments |
| Comment by Daniel Pasette (Inactive) [ 04/Mar/14 ] | |||
|
fixed in Update commands now return nMatched, nUpserted and nModified as distinct return fields.
| |||
| Comment by Scott Hernandez (Inactive) [ 20/Feb/13 ] | |||
|
What does nupdated mean if not the number of updated docs based on the update operation? Currently many clients expose and use "n" in the WriteResult (GLE response) as an indication of the number of affected documents. Perhaps we should add "nfound" to indicate the query matches and n/nupdated to indicate the modified/updated docs for backwards compatibility and based on current user understandings. From the user point of view, what is the difference of "updated" and "modified"? When do you ever update a document where you did not modify it? | |||
| Comment by Eliot Horowitz (Inactive) [ 20/Feb/13 ] | |||
|
"n" should be the number of documents matched | |||
| Comment by daniel.roberts@10gen.com [ 19/Feb/13 ] | |||
|
nupdated still reports 1 even though document no change in version 2.4.0-rc1-pre-
| |||
| Comment by Scott Hernandez (Inactive) [ 15/Feb/13 ] | |||
|
They are also recorded to the oplog which I assume is a side-effect of this bug. | |||
| Comment by Alberto Lerner [ 15/Feb/13 ] | |||
|
Some updates mods become no-ops, depending on the context in which they are executed, and the counters in those cases are off. This is a bug. |