Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-92126

Consolidate functions used for iterating PlanExecutor in bulkWrite update statements and update command

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 8.1.0-rc0
    • Affects Version/s: None
    • Component/s: Write Ops
    • None
    • Query Execution
    • Fully Compatible
    • QO 2024-07-08, QO 2024-07-22, QO 2024-08-05, QO 2024-08-19
    • 0

      Update statements can now appear in both the bulkWrite command (which is being adopted by drivers in DRIVERS-716) as well as in the update command. Individual update statements are more or less equivalent in both contexts, but they are currently implemented with separate code paths. (In the future, we may want to see if we can share more between code between the two.)

      Both paths execute updates by creating a classic engine PlanExecutor (a PlanExecutorImpl) and then iterating it in order to execute the update. However, the code to do so is not shared. The update command is implemented in terms of PlanExecutorImpl::executeUpdate() whereas the bulkWrite version is implemented in terms of a helper called advanceExecutor(). I imagine that the reason for this discrepancy is that bulkWrite supports findAndModify-style statements in which a deleted or updated document can be returned.

      That said, I don't see a good reason for the two code paths to use separate implementations of iterating the PlanExecutor. Indeed, this caused us to have to duplicate the code for fixing related ticket SERVER-91465. The work for this ticket is to see if PlanExecutorImpl::executeUpdate() and advanceExecutor() can be consolidated, removing the duplication introduced by SERVER-91465 in the process.

            Assignee:
            david.storch@mongodb.com David Storch
            Reporter:
            david.storch@mongodb.com David Storch
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: