782e4e64df
The aim here is to get to a stage where we have a `PersistEventStore` that holds all the write methods used during event persistence, so that we can take that class out of the `DataStore` mixin and instansiate it separately. This will allow us to instansiate it on processes other than master, while also ensuring it is only available on processes that are configured to write to events stream. This is a bit of an architectural change, where we end up with multiple classes per data store (rather than one per data store we have now). We end up having: 1. Storage classes that provide high level APIs that can talk to multiple data stores. 2. Data store modules that consist of classes that must point at the same database instance. 3. Classes in a data store that can be instantiated on processes depending on config. |
||
|---|---|---|
| .. | ||
| _scripts | ||
| api | ||
| app | ||
| appservice | ||
| config | ||
| crypto | ||
| events | ||
| federation | ||
| groups | ||
| handlers | ||
| http | ||
| logging | ||
| metrics | ||
| module_api | ||
| push | ||
| replication | ||
| res/templates | ||
| rest | ||
| server_notices | ||
| spam_checker_api | ||
| state | ||
| static | ||
| storage | ||
| streams | ||
| util | ||
| __init__.py | ||
| event_auth.py | ||
| notifier.py | ||
| python_dependencies.py | ||
| secrets.py | ||
| server.py | ||
| server.pyi | ||
| types.py | ||
| visibility.py | ||