[SERVER-20957] Change Format of getMore command Created: 15/Oct/15  Updated: 14/Mar/17  Resolved: 03/Nov/15

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: 3.1.9
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Durran Jordan Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screen Shot 2015-10-15 at 9.36.23 PM.png    
Issue Links:
Documented
is documented by DOCS-8956 Change Format of getMore command Closed
Backwards Compatibility: Major Change
Participants:

 Description   

The getMore command in the upcoming 3.2 release currently has a format of:

{
  "getMore": <int64>,
  "collection": <string>,
  "batchSize": <int64>,
  "maxTimeMS": <int32>
}

This is inconsistent with other commands that expect a collection name as one of their elements in the document - the expectation is that the command follows a format of (such as find, killCursors, update, delete, etc):

{ commandName: <string>, ... } 

I am proposing for consistency we change the getMore command to:

{
  "getMore": <string>,
  "cursor": <int64>,
  "batchSize": <int64>,
  "maxTimeMS": <int32>
}

Why does this matter?

The the introduction of command monitoring specification in the drivers and implementations already live in the wild from New Relic, etc expect that commands that execute on a collection follow a format of { commandName: collectionName } in order to generically parse the collection name from the events. Not following this format forces 3rd party subscribers to make exceptions based on the command name, which is against the principle of command monitoring to begin with – we wanted to provide them with an API to subscribe to without having driver or server changes force them to modify their APM subscribers.

Sorry for the late ticket, but I just noticed this now when working on a demo for New Relic for their FutureStack conference... A sample screen shot of what it looks like in New Relic based on their assumptions and our specification is attached - getMore is grouped by cursor id which causes them to not be able to group the events properly by collection without an exception for this case.

A link to the drivers' command monitoring specification:

https://github.com/mongodb/specifications/blob/master/source/command-monitoring/command-monitoring.rst



 Comments   
Comment by J Rassi [ 03/Nov/15 ]

This alternative format was proposed during the spec process for the find/getMore commands, however we ultimately decided against it. Right now, the collection parameter is necessary in order for the auth checking process, however we may deprecate or remove the collection parameter if it becomes unnecessary in a future server version.

As such, I'm closing this ticket as "Won't Fix".

Comment by Jeffrey Yemin [ 15/Oct/15 ]

Leaving aside whether this is a good idea or not, I think it's too late in the game to be changing this now. Some drivers have already released implementations of the command monitoring specification that assume the current structure of the getMore command, and one could argue that it would be a breaking change if we alter the format of the getMore command between releases.

I also think we're too close to the RC to be making this change in the 3.2 timeframe, but that's for others to decide.

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