This issue has been migrated from #11733.
Store, StateGroupDataStore, DataStore, Storage, DatabasePool, Databases... 🤯
#8033 made some attempts to clean it up, but there's a lot more to do here.
There are basically three layers:
-
a DatabasePool represents a connection to a physical database. Normally you have exactly one of these, but it's possible to set Synapse up to talk to two separate postgres instances (one of them gets used for state storage (state_groups_state, mainly), and the other for everything else), in which case you have two.
-
a <foo>Store is a low-level thing containing SQL, and is linked to a single DatabasePool. We basically have two of these (state and main), again with the state/everything else split. state is always a StateGroupDataStore, but main can be any of (DataStore, AdminCmdSlavedStore, GenericWorkerSlavedStore) depending on the synapse app.
PersistEventsStore seems to be a special case, and is a layer over the main store.
Databases is a singleton which instantiates the DatabasePools and <foo>Stores, and holds references to them.
-
a <foo>Storage is a higher-level thing which spans multiple <foo>Stores. Ideally it does not do any SQL itself, but delegates it all to the Stores. We have three of these (PurgeEventsStorage, StateGroupStorage, EventsPersistenceStorage). Note that a lot of non-storage code skips this layer and goes straight to the <foo>Stores.
Storage itself instantiates and holds references to the <foo>Storages.
Edit 2022/06/06: These are now known as <foo>StorageControllers, and Storage itself is now known as StorageControllers.
This is all very well, but I seem to be incapable of holding it in my head at once. This is really not helped by there being a lot of inconsistent naming. Examples:
This issue has been migrated from #11733.
Store,StateGroupDataStore,DataStore,Storage,DatabasePool,Databases... 🤯#8033 made some attempts to clean it up, but there's a lot more to do here.
There are basically three layers:
a
DatabasePoolrepresents a connection to a physical database. Normally you have exactly one of these, but it's possible to set Synapse up to talk to two separate postgres instances (one of them gets used for state storage (state_groups_state, mainly), and the other for everything else), in which case you have two.a
<foo>Storeis a low-level thing containing SQL, and is linked to a singleDatabasePool. We basically have two of these (stateandmain), again with the state/everything else split.stateis always aStateGroupDataStore, butmaincan be any of (DataStore,AdminCmdSlavedStore,GenericWorkerSlavedStore) depending on the synapse app.PersistEventsStoreseems to be a special case, and is a layer over themainstore.Databasesis a singleton which instantiates theDatabasePools and<foo>Stores, and holds references to them.a
<foo>Storageis a higher-level thing which spans multiple<foo>Stores. Ideally it does not do any SQL itself, but delegates it all to theStores. We have three of these (PurgeEventsStorage,StateGroupStorage,EventsPersistenceStorage). Note that a lot of non-storage code skips this layer and goes straight to the<foo>Stores.Storageitself instantiates and holds references to the<foo>Storages.Edit 2022/06/06: These are now known as
<foo>StorageControllers, andStorageitself is now known asStorageControllers.This is all very well, but I seem to be incapable of holding it in my head at once. This is really not helped by there being a lot of inconsistent naming. Examples:
Databasesshould surely be calledDataStoreManageror similar. AndHomeServer.get_datastores, which returns theDatabases, should be renamed.Storage->StorageManager. (superceded by Dummy issue #12913)Storecould do with being named as such, for consistency withStateGroupDataStore- egMasterMainDataStore,WorkerMainDataStore.HomeServer.get_datastore(which returns the mainStore) exists only for backwards compatibility. We should replace it with calls toget_datastores().mainfor consistency with theStateGroupDataStore. Dummy issue #12031self.storeshould instead have aself._main_store.