[SERVER-76657] Make bulkWrite override support multiple ops Created: 28/Apr/23 Updated: 29/Oct/23 Resolved: 26/May/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.1.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Sean Zimmerman | Assignee: | Sean Zimmerman |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | milestone-4 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Replication
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | Repl 2023-05-29 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
Building off of Special care will need to be taken with forming the responses for insert many / update many, will likely need some sort of bookkeeping to tell where the original request boundaries are in the bulkWrite ops Will need to determine when to split ops, which could include successive ops having different values for bypassDocumentValidation or ordered. A separate ticket should be made to determine if there are any ops which can be run without interrupting a bulkWrite batch When executing an ordered: true bulkWrite there will need to be special logic put in place to retry any ops that did not initially run. Note that this means we retry from where the next CRUD op was in the bulkWrite, not the next bulkWrite op (since we need to respect the ordered:true in the response for the CRUD op that failed so we don't rerun any unexecuted ops that belong to that CRUD op) |
| Comments |
| Comment by Githook User [ 25/May/23 ] |
|
Author: {'name': 'seanzimm', 'email': 'sean.zimmerman@mongodb.com', 'username': 'seanzimm'}Message: |