[SERVER-55284] Get rid of the ScopedAllowImplicitCollectionCreate_UNSAFE marker Created: 18/Mar/21 Updated: 20/Sep/21 Resolved: 20/Sep/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Kaloian Manassiev | Assignee: | Kaloian Manassiev |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
In This ticket is the last part of a set of dependent tickets to remove it from the various implicit collection creation paths. When this ticket is ready to be worked on, we should just rename that utility to something more meaningful and only use it in the CreateCollection coordinator. Without this ticket, implicitly created collections (through write to a non-existent collection for example) and those created through a call to create will not serialise with DropDatabase and could end-up getting lost. |
| Comments |
| Comment by Kaloian Manassiev [ 20/Sep/21 ] |
|
The ScopedAllowImplicitCollectionCreate_UNSAFE marker was added as a means to catch all places, which create collection outside of the sharded create collection protocol. Such places are inherently unsafe to exist, because they do not synchronise with a concurrent sharded DDL, most notably dropDatabase. While we have solved the dropDatabase synchronisation through the use of the database critical section, the markers should remain in place for when we start registering all collections in the sharded catalog. Closing as Won't Do. |