Uploaded image for project: 'Drivers'
  1. Drivers
  2. DRIVERS-817

updateOne, updateMany, deleteOne, and findAndModify without shard key

    • Type: Icon: Epic Epic
    • Resolution: Won't Fix
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Component/s: None
    • None
    • Done
    • updateOne without shard key
    • Hide

      Downstream changes summary:

      Show
      Downstream changes summary: for docs, we have created WRITING tickets calling out the documentation changes this project changes the explain output in certain conditions for updateOne, deleteOne, and findAndModify without a shard key. This is further specified in the Assumptions and Risks of the scope doc ( https://docs.google.com/document/d/1423XoTWWUOW1-spFqvDRMRIU8LQmgjmTzfXK51epoLA/edit#heading=h.sye21yee6q34 )

      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

            Assignee:
            jmikola@mongodb.com Jeremy Mikola
            Reporter:
            backlog-server-pm Backlog - Core Eng Program Management Team
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: