[SERVER-35906] Decouple the interfaces of the OpObserverRegistry, the generic OpObservers, and the ReplicationOpObserver Created: 28/Jun/18 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Spencer Brody (Inactive) | Assignee: | Backlog - Replication Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | former-quick-wins | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Replication
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
The ReplicationOpObserver is fundamentally special. It is responsible for generating OpTimes and writing oplog entries. No other OpObserver should ever generate an OpTime or oplog entry. Currently all OpObservers and the OpObserverRegistry implement the OpObserver interface, which includes returning OpTimes for some (but not all) observer methods, even though the majority of OpObservers must not generate optimes and thus always return null optimes. Rather than trying to coerce these different objects into having the same interface, we should acknowledge that the OpObserverRegistry isn't an OpObserver, and the ReplicationOpObserver is different from all other OpObservers. This would allow the ReplicationOpObserver and the OpObserverRegistry to return OpTimes as needed, without complicating the API for the rest of the generic OpObservers |
| Comments |
| Comment by Spencer Brody (Inactive) [ 28/Jun/18 ] |
|
This, along with the linked tickets, are part of theme of work around refactoring the OpObserver subsystem. We made some changes to the OpObservers in 4.0 that left them in a bit of a weird state that is difficult to understand. Also transactions and other projects rely heavily on the OpObservers - making them easier to understand, use, and unit test would be a high value improvement to the code base. |
| Comment by Spencer Brody (Inactive) [ 28/Jun/18 ] |
|
As part of this we should consider if there's still a way to make the compiler enforce that if a method is added to one of the three interfaces that it must be added to the other two as well. |