[SERVER-55145] Make dropping a nonexistent database a noop Created: 11/Mar/21  Updated: 29/Oct/23  Resolved: 16/Mar/21

Status: Closed
Project: Core Server
Component/s: Replication, Sharding
Affects Version/s: None
Fix Version/s: 4.9.0

Type: Task Priority: Major - P3
Reporter: Tommaso Tocci Assignee: Tommaso Tocci
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Documented
is documented by DOCS-14296 Investigate changes in SERVER-55145: ... Closed
Duplicate
is duplicated by SERVER-54100 Remove _shardsvrDropDatabase command ... Closed
Related
related to SERVER-58864 dropDatabase should return some detai... Closed
is related to SERVER-43894 Make dropping a nonexistent collectio... Closed
is related to DRIVERS-2118 Create collection and database manage... Backlog
Backwards Compatibility: Minor Change
Sprint: Sharding 2021-03-22
Participants:

 Description   

Currently when dropping a nonexistent database, we return a response that contains information about if the database previously existed or not.
 - On replicaset
 - On sharded cluster

This response is not reliable if a step-down happens during the operation, in fact on step-down the operation is automatically retried on the new replicaset primary. On this new node we don't have any way of assessing previous existence of the database because the old primary could have either already drop it or not.

Moreover the drop database response is not currently documented anywhere.

The goal of this ticket is to simplify the drop database response by not returning any information on the previous state of the database being dropped.



 Comments   
Comment by Githook User [ 16/Mar/21 ]

Author:

{'name': 'Tommaso Tocci', 'email': 'tommaso.tocci@mongodb.com', 'username': 'toto-dev'}

Message: SERVER-55145 Make dropping a nonexistent database a noop
Branch: master
https://github.com/mongodb/mongo/commit/b134809bd5db091c0517ee0fb4378ad420a5c021

Generated at Thu Feb 08 05:35:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.