The ReadOnlyMode service currently requires LoadBalancer, which means migration to LBFactory/ConnectionProvider can't be completed in some cases.
Example: UserGroupManager
$this->loadBalancerFactory = $loadBalancerFactory; $loadBalancer = $loadBalancerFactory->getMainLB( $wikiId ); // Can't inject main ROM service, as this can be for a foreign wiki $this->readOnlyMode = new ReadOnlyMode( $configuredReadOnlyMode, $loadBalancer );
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | aaron | T326187 Make LoadBalancer::getReaderIndex handle down groups better | |||
| Open | Ladsgroup | T343098 [epic] Data Persistence Hypothesis WE 3.2.1 | |||
| Resolved | Ladsgroup | T326274 Reduce complexity of LB and LBF (introducing IConnectionProvider) | |||
| Resolved | Ladsgroup | T343917 Support ReadOnlyMode without internal LoadBalancer |
Perhaps read-only status is widely used enough to justify one more method on ConnectionProvider, or alternatively add it only to LBFactory. It'd take $domain as argument, and figure out from there which LB to get it from internally (the implementation can move, but for now it'd likely come from LB).
Such method would suffice for code needing last-minute read-only information, however for the ReadOnlyMode class it would not suffice since ReadOnlyMode wouldn't know which $domain to pass. One way out of this might be for LBFactory to own creation of na ReadOnlyMode instance, from something like LBFactory->getReadOnlyMode($domain=false): ReadOnlyMode. That'd require a change to the ReadOnlyMode signature to e.g. take LBFactory+domain as parameters or something.
My very initial thought: ReadOnlyMode is something quite global and in some cases it doesn't have anything to do with the database. You might want to set the wiki to read only for any reason. I think having a dedicated service such as "read only mode" would be quite useful, we would inject that into LBF chain and then set the read only mode in case LB decides it should be read only.
More like a global config variable masquerading as a service with a setter. How hard it would be implement it?
The good news is that we do already have ReadOnlyMode service, the bad news is that we have both ReadOnlyMode service and ConfiguredReadOnlyMode. They probably need an overhaul.
Change 948220 had a related patch set uploaded (by Krinkle; author: Krinkle):
[mediawiki/core@master] UserGroupManager: Adopt IConnectionProvider
Change 948220 merged by jenkins-bot:
[mediawiki/core@master] UserGroupManager: Adopt IConnectionProvider
Change 955917 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):
[mediawiki/core@master] rdbms: Add support for per-domain calls in ReadOnlyMode
Change 955917 merged by jenkins-bot:
[mediawiki/core@master] rdbms: Add support for per-domain calls in ReadOnlyMode
Change 956487 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):
[mediawiki/core@master] Deprecate ConfiguredReadOnlyMode service
Change 956488 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):
[mediawiki/extensions/Wikibase@master] EditEntity: Use ReadOnlyMode instead of ConfiguredReadOnlyMode
Change 956488 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] EditEntity: Use ReadOnlyMode instead of ConfiguredReadOnlyMode
Change 956487 merged by jenkins-bot:
[mediawiki/core@master] Deprecate ConfiguredReadOnlyMode service