[SERVER-12858] Return detailed stats from write commands Created: 24/Feb/14  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Write Ops
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Robert Moore Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 1
Labels: commands, write
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-3920 Get object IDs for mutated objects af... Backlog
is related to SERVER-13054 Statistics from write commands Closed
is related to SERVER-33121 Add updated/deleted _id's to response... Closed
Assigned Teams:
Query Execution
Backwards Compatibility: Minor Change
Participants:

 Description   

The new commands for insert, delete and update currently only return the total number of documents deleted and modified.

This significantly reduces the utility of batching since it is impossible for the user to now what actually happened for each update and delete that leads to users falling back to not batching the updates and deletes which negates the purpose of the command in the first place.

Simply adding an array to the output for the delete and update containing the details for each operation similar to the following will allow users to use the batching commands: (cribbing from the docs)

db.runCommand(
   {
      delete: "orders",
      deletes: [
         { q: { status: "D" }, limit: 0 },
         { q: { cust_num: 99999, item: "abc123", status: "A" }, limit: 1 }
      ],
      ordered: false,
      writeConcern: { w: 1 }
   }
)
{ 
   "ok" : 1, 
   "n" : 21
   "deletes" : [ 21, 0 ]
}

In this example we see that the single delete did not actually delete any documents. It is easy to imagine a situation where that may be important.

db.runCommand(
   {
      update: "users",
      updates: [
         { q: { status: "P" }, u: { $set: { status: "D" } }, multi: true },
         { q: { _id: 5 }, u: { _id: 5, name: "abc123", status: "A" }, upsert: true }
      ],
      ordered: false,
      writeConcern: { w: 1 }
   }
)
{
   "ok" : 1,
   "nDocsModified" : 10,
   "n" : 11,
   "upserted" : [
      {
         "index" : 1,
         "_id" : 5
      }
   ]
   "modified" : [ 10, 1 ]
}

In this case we could have already determined that the first update had modified 10 documents since the second happened to be an upsert. In general this will not be the case.



 Comments   
Comment by Adam Comerford [ 23/Jul/14 ]

For updates, it would be great to have at least a subset of the stats in the profiler and at a minimum "moved" : true, "nmoved" : 1 and similar would be very informative

Comment by Marc Tinkler [ 28/Feb/14 ]

It would be fantastic if all write commands also returned the timestamp of the oplog when they were completed.

This would allow you to then add a query readPreference where you could specify secondaryPreferred, but wait for a given oplog timestamp. This would be somewhat more flexible than just having a write concern of replica acknowledged.

Comment by Robert Moore [ 28/Feb/14 ]

I was really hoping this would make it into 2.6.

Rob.

Generated at Thu Feb 08 03:29:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.