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

Build commands after connection checkout

    • Type: Icon: Task Task
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Connection Layer
    • 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?

      Use Case

      The Node driver's operation execution flow looks roughly like the following:

      • check if connected, auto connect if needed
      • select server
      • obtain session
      • build the command
      • checkout a connection
      • execute the command

      Some operations require information about the selected server (maxWireVersion,  maxBSONSize, etc) when constructing the command.  This data is usually obtained from the server's server description, which is populated after the monitor connects during SDAM.

      In load balanced mode, we don't perform SDAM.  This means that any command that relies on data from the server description might not have accurate information.

      There are two solutions to this problem that I can think of:

      1. propagate handshake information from connection establishment up into the topology and store it in a fake server description for LB mode specifically.
      2. build commands after connection checkout, obtaining server information from the connection's `StreamDescription`

      Of these options, 2 seems like a better solution.

      User Experience

       

      Dependencies

      n/a

      Risks/Unknowns

      n/a

      Acceptance Criteria

      Implementation Requirements

      • functional reqs, potential snafus to avoid, performance targets, etc

      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:
            bailey.pearson@mongodb.com Bailey Pearson
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: