[SERVER-35840] dropDatabase may log a confusing number of collection drops Created: 27/Jun/18  Updated: 29/Oct/23  Resolved: 31/Dec/18

Status: Closed
Project: Core Server
Component/s: Logging, Storage
Affects Version/s: None
Fix Version/s: 4.1.7

Type: Bug Priority: Major - P3
Reporter: Kelsey Schubert Assignee: Gregory Wlodarek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
related to SERVER-35836 Client connection executed dropDatabase Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.0, v3.6
Steps To Reproduce:

Observed on 3.6.5 on macOS

db.foo.insert({})
db.dropDatabase()

In the logs:

2018-06-27T06:38:26.738-0400 I COMMAND  [conn6] dropDatabase test - starting
2018-06-27T06:38:26.738-0400 I COMMAND  [conn6] dropDatabase test - dropping 0 collections
2018-06-27T06:38:26.768-0400 I COMMAND  [conn6] dropDatabase test - finished

Sprint: Storage NYC 2018-12-31, Storage NYC 2019-01-14
Participants:

 Description   

I believe that if a collection is dropped very quickly as part of dropDatabase, we do not count it in the dropDatabase command. This can confuse some users since we may log that no collections were dropped. We could either make this number always accurate or clarify what metric it is tracking.



 Comments   
Comment by Githook User [ 31/Dec/18 ]

Author:

{'username': 'GWlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'name': 'Gregory Wlodarek'}

Message: SERVER-35840 Log the appropriate number of collections dropped using dropDatabase()
Branch: master
https://github.com/mongodb/mongo/commit/3c8cb76aa52325ad3cac3b9419e675188f380820

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