[SERVER-714] Allow findandmodify to retreive more than 1 record at a time Created: 08/Mar/10  Updated: 06/Dec/22

Status: Open
Project: Core Server
Component/s: Write Ops
Affects Version/s: None
Fix Version/s: features we're not sure of

Type: Improvement Priority: Minor - P4
Reporter: Marc Seeger Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 15
Labels: findAndModify, transactions
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-17256 findAndModify for multiple documents Closed
is duplicated by SERVER-30960 Find and Modify Many Closed
is duplicated by SERVER-2106 findAndModify a batch WAS: It would ... Closed
is duplicated by SERVER-28048 findAndModify support for multiple do... Closed
is duplicated by SERVER-33121 Add updated/deleted _id's to response... Closed
Related
is related to SERVER-42741 getting back both _id of modified doc... Backlog
is related to SERVER-3920 Get object IDs for mutated objects af... Backlog
Assigned Teams:
Query Execution
Participants:
Case:

 Description   

It would be nice to have the possibility to atomically retrieve more than one document without looping x times and getting one document each time



 Comments   
Comment by Zach Bjornson [ 31/Oct/19 ]

(Regarding the functionality described in SERVER-33121, marked as duplicate of this, to get back the deleted _id s from deleteMany .)

For comparison, PostgreSQL supports DELETE FROM ... RETURNING * | output_expression, which allows you to e.g. return the array of IDs that were deleted. (Or anything, for that matter.)

Comment by Toni [ 11/Dec/12 ]

This would be a dream come true feature! In our case, the findAndModify looping is a terrible hassle and load-booster deluxe, as we have many users potentially updating the same records 'in parallel'. So far, our solution is sending a .find to retrieve the _id's of all documents matching the update selector, then run the update with multi:true, then run a find using $in:_idArray as a selector (as the original update selector could return different documents, depending on whether (a) other users ran updates in between or (b) the update changed selector fields. )
This is three complex actions instead of a 'simple' update multi:true that would return all affected documents. I imagine the update will have to read in every affected document anyways, so this would be a significant jump in both speed and usability for apps that need to run multi-updates within one request. Quite a large proportion i guess.

Generated at Thu Feb 08 02:54:57 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.