[DRIVERS-817] updateOne, updateMany, deleteOne, and findAndModify without shard key Created: 30/Jan/20  Updated: 13/Jun/23  Resolved: 07/May/20

Status: Closed
Project: Drivers
Component/s: None
Fix Version/s: None

Type: Epic Priority: Major - P3
Reporter: Backlog - Core Eng Program Management Team Assignee: Jeremy Mikola
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to DRIVERS-818 updateMany without shard key Closed
is related to MONGOID-4759 Change updates to prefer target by th... Backlog
Server Compat: 7.1
Quarter: FY21Q1
Upstream Changes Summary:

Downstream changes summary:


 Description   
Downstream Change Summary

Haven't started scoping yet but suspect this will need drivers changes.

Description of Linked Ticket

Epic Summary

Summary

Allow updateOne (i.e. update with multi:false), deleteOne (i.e delete with limit:1), and findAndModify without a shard key or _id equality in their filter to work against a sharded collection, supporting all options.

Motivation

The current implementation of updateOne, deleteOne, and findAndModify against a sharded collection requires that the request can be unequivocally routed to a single shard (i.e. the shard key must be in the filter) or, for updateOne and deleteOne, that the document to be modified can be uniquely identified through its _id. If these requirements are not satisfied, these writes fail, which makes the presence of sharding underneath more apparent and prevents automatically sharding a user’s collection, which is at odds with the long term vision for serverless MongoDB.

Documentation

Scope Document
Technical Design Document

Epic Summary

Summary

This project proposes making updateMany, without a shard key in the filter, work correctly against a sharded collection, for all combinations of ordered:true/false and upsert:true/false. We will consider several ways to implement this - using transactions against all concurrently targeted shards or using two-phase updates where the first phase establishes cursors and the second phase performs the actual updates.

Motivation

The current implementation of updateMany against a sharded collection doesn’t work correctly, because it doesn’t synchronise with chunk migrations and doesn’t perform chunk filtering. As a result, it has the potential of applying updates to the same document between zero and multiple times. Furthermore, it the upsert:true option requires that a shard key be specified so that a unique shard can be targeted.

Documentation

Scope Document
Technical Design Document



 Comments   
Comment by Jeremy Mikola [ 08/May/20 ]

Syncing descriptions from PM-1631 and PM-1632.

Generated at Thu Feb 08 08:22:26 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.