-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Catalog and Routing
-
3
Currently we react to any change to the system.views collection (other than dropping it) by explicitly reloading the view catalog for the database. This was necessary back when we allowed direct user writes to the system, so invalid view definitions could be persisted. Since SERVER-43633 prohibited direct user writes to the system.views collection, we could now handle operations with a bit more finesse.
In particular, we could add different handlers for insert, update, and delete, to make more granular updates to the CollectionCatalog. We may want to refactor a bit to share functionality with the createView, modifyView, and dropView functions, without generating additional oplog entries; however, it's also possible we want a completely separate code path for handling the oplog entries as the logic we perform will likely not use the same type of error handling.
- depends on
-
SERVER-57250 CollectionCatalog should handle and own Views instead of ViewCatalog
- Closed
- is related to
-
SERVER-63749 Put view validation logic on applyOps direct writes to <db>.system.views
- Backlog
-
SERVER-53870 Improve view creation performance over time
- Closed