[SERVER-25235] Views should drop 'singleBatch' if 'limit' is 1 Created: 22/Jul/16  Updated: 02/Sep/16  Resolved: 16/Aug/16

Status: Closed
Project: Core Server
Component/s: Aggregation Framework
Affects Version/s: None
Fix Version/s: 3.3.12

Type: Improvement Priority: Major - P3
Reporter: Kyle Suarez Assignee: Kyle Suarez
Resolution: Done Votes: 0
Labels: read-only-views
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-25190 Unit tests for view transformations t... Closed
Related
related to SERVER-24766 implement basic view functionality Closed
Backwards Compatibility: Fully Compatible
Sprint: Integration 2016-08-29
Participants:

 Description   

As a special case, when transforming a find into an aggregation for a query on a view, the singleBatch option will be dropped if specified when the limit is exactly 1. This allows queries that specify {limit: 1, singleBatch: true} to be sent against a view; without this, the aggregation system would reject the transformed command.

This allows some driver implementations of find_one() to work with views.

Original Description

Drivers that implement the CRUD specification may send the singleBatch option to implement methods like find_one() (for example, PyMongo does this).

This works for the find command, but the aggregation command does not support it. This makes it impossible to perform a find_one on a view namespace, as it translates all query operations into aggregations.



 Comments   
Comment by Kyle Suarez [ 16/Aug/16 ]

With the latest commit, views now supports drivers who specify singleBatch in their findOne helpers. There's also an integration test that tests views with the server's version of findOne.

Comment by Githook User [ 16/Aug/16 ]

Author:

{u'username': u'ksuarz', u'name': u'Kyle Suarez', u'email': u'kyle.suarez@mongodb.com'}

Message: SERVER-25235: singleBatch special case in QueryRequest::asAggregationCommand

When converting a QueryRequest into an aggregation command, drop the
'singleBatch' option if 'limit' is present and set to 1.
Branch: master
https://github.com/mongodb/mongo/commit/e7661304b820b16ad51f4485617031f9188b9229

Comment by David Storch [ 25/Jul/16 ]

A few notes from my offline conversation with kyle.suarez:

  • The singleBatch true option only exists in find command to ensure that the find command has feature parity with legacy OP_QUERY find. It shouldn't be necessary for most applications, since the combination of batchSize and limit should cover the main use cases.
  • The shell may be setting singleBatch on a findOne(), however, it probably shouldn't. In 3.2, findOne() can be accomplished with a find command using a limit of 1.
  • We should check with drivers to see in what cases a driver might end up sending a find command to the server with the singleBatch option set.
Comment by Asya Kamsky [ 25/Jul/16 ]

Note this applies to any negative batch size on views:

test@local:33900(3.3.10-96-g7f17bd8) > db.customerService.find().limit(-2)
Error: error: {
	"ok" : 0,
	"errmsg" : "Option singleBatch not supported in aggregation.",
	"code" : 168
}

Comment by Kyle Suarez [ 25/Jul/16 ]

That sounds feasible. I believe we can accomplish this in QueryRequest::asAggregationCommand() – instead of returning a non-OK status if _wantMore is set, we just add an additional $limit of 1 immediately after the $match.

Comment by David Storch [ 25/Jul/16 ]

I'm not sure it makes sense to add this functionality to the aggregation system. The notion of singleBatch doesn't seem particularly useful when there is already both batchSize and limit functionality. (In query land, this is holdover from the days of ntoreturn, when limit and batchSize were encapsulated in a single value.) Why can't findOne() be accomplished in agg using {$limit: 1}?

Comment by Bernie Hackett [ 22/Jul/16 ]

To add a bit more color, most drivers support a negative limit. In OP_QUERY a negative ntoreturn tells the server to return as much as it can in one batch and close the cursor (or maybe never create a cursor in the first place?). Drivers have to keep supporting the same behavior to avoid breaking existing applications.

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