Uploaded image for project: 'Node.js Driver'
  1. Node.js Driver
  2. NODE-6471

Ensure findOne does not set batchSize=1

    • Type: Icon: Task Task
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: CRUD
    • Hide

      DRIVERS-3009:
      In 2362d1a, the `findOne` operation is properly specified and spec tests added. Note that the API is still optional, and drivers that do not implement `findOne` should skip the new tests in source/crud/tests/unified/findOne.

      It's suggested to combine this work with DRIVERS-1447.

      Show
      DRIVERS-3009 : In 2362d1a , the `findOne` operation is properly specified and spec tests added. Note that the API is still optional, and drivers that do not implement `findOne` should skip the new tests in source/crud/tests/unified/findOne . It's suggested to combine this work with DRIVERS-1447.
    • Hide

      1. What would you like to communicate to the user about this feature?
      2. Would you like the user to see examples of the syntax and/or executable code and its output?
      3. Which versions of the driver/connector does this apply to?

      Show
      1. What would you like to communicate to the user about this feature? 2. Would you like the user to see examples of the syntax and/or executable code and its output? 3. Which versions of the driver/connector does this apply to?

      This ticket was split from DRIVERS-3009, please see that ticket for a detailed description.

      Use Case

      As a Node engineer
      I want to run "findOne" commands optimally
      So that the driver uses as little resources as possible to run this operation

      FindOne is a common API that a lot of drivers implement. It is a corner case of a cursor returning command that the driver can be sure in advance it will only receive one batch and the cursor should be closed server-side before the firstBatch response returns.

      (Why is this unique to find One? Even two documents can result in an unclosed cursor because each document can be equal to the max size forcing each to be returned in its own batch)

      User Experience

      • What is the desired/expected outcome for the user once this ticket is implemented?
      • If bug: What is the number of impacted customers? How severe is the impact? Is anyone blocked or broken?

      Dependencies

      • upstream and/or downstream requirements and timelines to bear in mind

      Risks/Unknowns

      • What could go wrong while implementing this change? (e.g., performance, inadvertent behavioral changes in adjacent functionality, existing tech debt, etc)
      • Is there an opportunity for better cross-driver alignment or testing in this area?
      • Is there an opportunity to improve existing documentation on this subject?

      Acceptance Criteria

      Implementation Requirements

      • Sync spec test changes and ensure findOne commands are built properly according to the clarifications made in the spec
      • If possible investigate executing find as a "runCommand" instead of via a cursor.next() to avoid the overhead of cursor construction and cleanup.

      Testing Requirements

      • unit test, spec test sync, etc

      Documentation Requirements

      • DOCSP ticket, API docs, etc

      Follow Up Requirements

      • additional tickets to file, required releases, etc
      • if node behavior differs/will differ from other drivers, confirm with dbx devs what standard to aim for and what plan, if any, exists to reconcile the diverging behavior moving forward

            Assignee:
            Unassigned Unassigned
            Reporter:
            dbeng-pm-bot PM Bot
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: