[SERVER-40718] Validate parameters for estimatedDocumentCount Created: 18/Apr/19  Updated: 06/Dec/22  Resolved: 18/Feb/22

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

Type: Improvement Priority: Major - P3
Reporter: Jason R. Coombs Assignee: Backlog - Query Optimization
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-37690 countDocuments throws an error when m... Closed
Assigned Teams:
Query Optimization
Participants:

 Description   

The documentation for `estimatedDocumentCount` is a bit confusing.

It seems that both MongoDB (shell) and PyMongo allow passing arbitrary, meaningless options. In PyMongo, I've been calling the function thus:

db.coll.estimated_document_count(
        filter=query, limit=limit, maxTimeMS=10000)

Not realizing that the filter and limit had no effect.

I've tested and the shell also silently accepts arbitrary fields:

rs0:PRIMARY> db.coll.estimatedDocumentCount({"foo": "bar"})
1

I try to imagine what is the value of accepting arbitrary keyword arguments. I could imagine that some future version of MongoDB might honor other parameters for that query, so you'd like to support that interface before it exists. Even for that use-case, I'd expect the server to respond with some warning or errors about unused parameters, especially when the docs say "this method wraps the count command", which does take more parameters.

Can this call be made so that it rejects invalid parameters?



 Comments   
Comment by Asya Kamsky [ 02/May/19 ]

This should perhaps be a part of cleaning up all the count replacement helper method issues.  SERVER-37690 is another example.

 

Comment by Eric Sedor [ 22/Apr/19 ]

Thank you for the example. We're assigning this ticket to the appropriate team to be evaluated against our currently planned work. Updates will be posted on this ticket as they happen.

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