[DRIVERS-2664] Remove cursorType option from runCursorCommand API Created: 26/Jun/23  Updated: 25/Jul/23  Resolved: 11/Jul/23

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

Type: Spec Change Priority: Unknown
Reporter: Noah Stapp Assignee: Shane Harvey
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Epic Link: DRIVERS-2533
Driver Changes: Needed
Quarter: FY24Q1

 Description   

The current spec for runCursorCommand requires a cursorType option that allows users to define the behavior of their cursor with respect to tailable and awaitData. However, users can already set this behavior in the command to be run itself, making this option redundant. It is trivial to implement this option as currently specified, but in the interest of maintaining a minimal, clean interface this option should be removed from the spec.



 Comments   
Comment by Shane Harvey [ 11/Jul/23 ]

Spoke the Neal in person. The conclusion we reached is that cursorType is actually needed for drivers that implement the timeoutMode feature in CSOT.

Comment by Jeremy Mikola [ 27/Jun/23 ]

I asked about this in the original PR for DRIVERS-2533. Quoting mongodb/specifications#1412:

jmikola@mongodb.com: What is the purpose of the cursorType option? From my experience implementing the existing API in PHP (where our existing runCommand method automatically creates command cursors based on the server response), we never had to consider such a property.

Regardless of whether a cursor is tailable or non-tailable, the driver only checks the cursor.id field in the response to determine if the cursor is still alive (i.e. subsequent getMore commands can be issued).

And awaitData is merely an implementation detail on the server-side.


neal.beeken@mongodb.com: This is only for CSOT, we need this external information about the command being run for how the cursor is supposed to apply timeoutMS to getMores correctly

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