[SERVER-43894] Make dropping a nonexistent collection a noop Created: 08/Oct/19 Updated: 29/Oct/23 Resolved: 09/Feb/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.0.0-rc0 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Oleg Pudeyev (Inactive) | Assignee: | Dianna Hohensee (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Execution Team 2023-02-20, Execution Team 2023-02-06 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 100 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Currently dropping a nonexistent collection is an error ( |
| Comments |
| Comment by Githook User [ 14/Feb/23 ] |
|
Author: {'name': 'Anna Henningsen', 'email': 'anna.henningsen@mongodb.com', 'username': 'addaleax'}Message: fix(shell-api): adjust .drop() return value for server changes (#1406) See |
| Comment by Githook User [ 10/Feb/23 ] |
|
Author: {'name': 'Anna Henningsen', 'email': 'anna.henningsen@mongodb.com', 'username': 'addaleax'}Message: fix(shell-api): adjust .drop() return value for server changes (#1406) See |
| Comment by Githook User [ 09/Feb/23 ] |
|
Author: {'name': 'Anna Henningsen', 'email': 'anna.henningsen@mongodb.com', 'username': 'addaleax'}Message: fix(shell-api): adjust .drop() return value for server changes See |
| Comment by Githook User [ 09/Feb/23 ] |
|
Author: {'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@mongodb.com', 'username': 'DiannaHohensee'}Message: |
| Comment by Daniel Gottlieb (Inactive) [ 25/Oct/19 ] |
I might be making a wrong assumption here. Suppose the spec mandates ignoring `ns not found` errors and the next mongodb version contains a patch for this ticket. I agree that drivers talking to the new version would never need to handle an `ns not found` error. But if a driver were talking to an older version of mongodb, wouldn't it be appropriate for the driver to explicitly ignore any `ns not found` error? If that's true, doing this ticket won't actually save any driver work. Or would that state be considered good enough? Where the API provided by the driver for drop collection changes based on which server version an application is connected to. |
| Comment by Oleg Pudeyev (Inactive) [ 10/Oct/19 ] |
|
To my knowledge there is no specification covering dropping collections. There was a survey of drivers recently as to how they handle the nonexisting ns error with the following results: Node - no special handling (error propagates to applications) There is an open spec ticket (https://jira.mongodb.org/browse/SPEC-1053) to specify collection dropping behavior, specifically what to do about 'ns not found' error, in a consistent way across drivers. As far as existing driver behavior is concerned, if the server stopped producing errors in the case of nonexistent collections, the drivers' behavior remains the same and backwards compatible, unless I am missing something. Given that the spec ticket above proposes to mandate ignoring 'ns not found' errors, if the server was to not return this error at all this would potentially save work across all drivers. |
| Comment by Daniel Gottlieb (Inactive) [ 10/Oct/19 ] |
|
oleg.pudeyev, I strongly agree with you that the server should treat dropping a non-existent collection a success. However, this behavior dates back for as long as I can remember and I'm worried that the downstream impact would result in more work than the alternative; simply having drivers cope with the response as it is today. A change like this can only go into newer versions of MongoDB. I suspect drivers, in an effort to present a uniform API to clients, would still have to look for and transform drop "failures" because the collection does not exist into the successful variety. Otherwise, a driver may or may not report an error to the calling code with the only variable being the server version that it was talking with. That being said, if there's buy-in among driver API stakeholders, we can do this. There are some subtle bugs we'd have to avoid (e.g: a WriteConcern: majority dropCollection cannot simply return) but it's certainly doable. Would you like to raise this issue with the driver teams? |