[SERVER-76342] Drop system.views when the last view is removed Created: 20/Apr/23 Updated: 30/Jan/24 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Felipe Gasper | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Unresolved | Votes: | 4 |
| Labels: | read-only-views | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
Currently system.views stays around even after the last view is dropped. This can result in confusion behavior like the following: 1. Create a collection "stuff" in db "foo". OBSERVE: foo.system.views still exists, although it's empty. 4. Try to recreate the collection from step 1 but on db "Foo". (Note the case difference.) OBSERVE: This fails with DatabaseDifferCase. |
| Comments |
| Comment by Dominik Herbst [ 31/Jul/23 ] | ||||||||||||||||||||||
|
We also observed the described behavior that system.views remains when all views are removed. In our special case we are using MongoDB Atlas with a user that has the built in readWrite role. This roles does not allow operations on system collections. The use case is a cleanup of the database. So we drop all collections to achieve a removal of the database. But it does not work because the system.views collection stays there. In our case the system.views collection was created by creation of a timeseries collection. Dropping the timeseries collection, drops the system.buckets.* collection, but nor the system.views collection. | ||||||||||||||||||||||
| Comment by Felipe Gasper [ 26/May/23 ] | ||||||||||||||||||||||
|
This seems to need more investigation. In brief: mongosync runs into problems when a DB’s only content is an empty system collection (e.g., system.views). We can’t drop the database directly because we need to drop collections by their UUID. Since dropping the DB includes dropping system collections, it seems that whatever role allows dropping a database should also confer the ability to drop that database’s system.views. | ||||||||||||||||||||||
| Comment by Felipe Gasper [ 26/May/23 ] | ||||||||||||||||||||||
|
A user with these permissions:
… lacks authorization to delete test.system.views. Based on this, I believe right now the server requires admin rights to delete system.views. | ||||||||||||||||||||||
| Comment by Felipe Gasper [ 02/May/23 ] | ||||||||||||||||||||||
|
gregory.noma@mongodb.com Yes, as far as I know. REP-33’s design doc gives the rationale: https://docs.google.com/document/d/1jbbsAORfJBiiDRXAVc1HyIqUqcW_68LlJOuUULGv6nA/edit#heading=h.t7g1m1i0si3w | ||||||||||||||||||||||
| Comment by Gregory Noma [ 02/May/23 ] | ||||||||||||||||||||||
|
> having mongosync drop a DB by its name would risk deleting the wrong data felipe.gasper@mongodb.com Is this still the case despite the fact that databases can't be renamed? | ||||||||||||||||||||||
| Comment by Felipe Gasper [ 02/May/23 ] | ||||||||||||||||||||||
|
fausto.leyva@mongodb.com: Unfortunately, mongosync can’t dropDatabase() because DBs lack UUIDs, and having mongosync drop a DB by its name would risk deleting the wrong data. Mongosync also can’t drop the DB’s `system.views` without requiring special privileges, which we want to avoid. | ||||||||||||||||||||||
| Comment by Fausto Leyva (Inactive) [ 02/May/23 ] | ||||||||||||||||||||||
|
The user should use dropDatabase instead, so they could create a separate collection with different db casing. |