When $wgMainCache is CACHE_ANYTHING, recursion proceeds via
LoadBalancer::isPrimaryRunningReadOnly() until the DB server hits its
maximum connection limit. The try/catch blocks in ServiceWiring were no
longer effectively preventing this.
So, inspect the configuration to detect whether the main cache type will
be CACHE_DB, without actually instantiating it.
Bug: T334970
Change-Id: Ibdbc19c45eb20bb85df720669f7ce1d50e3656ff
This is preparation for re-using it in the MainWANObjectCache
service in a way that preserves proper dependency injection.
This is related to a declined task (T243233) which proposed offering
it as a non-internal service. It is expected to remain internal, with
public callers generally migrated to WANObjectCache or WRStats or
in some cases to a (not yet implemented) lock manager service.
Bug: T329680
Change-Id: I8af9667529b4896f17a22b66823e7eac859d4229
We'd lose more useful coverage and spend more effort keeping these
accurate through refactors etc than is worth the theoretically "bad"
accidental coverage. Plus, even then we still very often forget to
update these and waste time digging into seemingly uncovered code
and either write duplicate test or discover they are already covered.
Especially for private methods this can be a flawed endavour as
we tend to trust tests when changing those and thus feel we shouldn't
update tests, except it's riddled with private method mentions for
coverage purposes (not in terms of actual called code).
I think the best practice is to write good narrow unit tests,
not to write bad tests and then hide their coverage. Generally
that's what we do. Maybe these are useful when invoking a huge
legacy class, but generally we don't need these I think, at least
in the libs our team maintains.
Change-Id: I4c7d826c7ec654b9efa20778c46c498784661f1c
Subclasses of Maintenance that can function without database access can
now override canExecuteWithoutLocalSettings to return true.
This is useful for scripts that need to be able to run before or without
installing MediaWiki.
When no config file is present, the storage backend will be disabled.
Any attempt to access the database will result in an error.
NOTE: This makes MediaWikiServices::disableBackendServices() more
comprehensive, to avoid premature failures during service
construction. This change makes it necessary to adjust how the
installer manages service overrides.
The CLI installer is covered by CI, I tested the web installer
manually.
Change-Id: Ie84010c80f32cbdfd34aff9dde1bfde1ed531793
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
Now that resetServices() will preserve (but reset) customized services,
it should be reasonably safe to call it every time globals are changed,
and much more effective than relying on tests to call it every time
themselves.
Depends-On: Iab8ea3a61bbc6803805d855ef23c071067646f71
Depends-On: I00e35ecea6a27468674b2a6e7d9d9eb6518e3bd5
Change-Id: Ie7a89f6ed7d52a0bc01672019ff92e7ee105a1f3
* Fix typo that disabled testNewAnythingNoAccel().
Follows-up c5a0fa5bed, accidentally committed a local hack
to disable the test.
* Add missing case other types falling back and no DB.
* Add missing case of no other types and no DB.
Change-Id: If158f21053f0b3741f2625fe4455fdb31955a22f
If $wgMainCacheType = CACHE_ACCEL, but there is no APC, then its
possible that CACHE_ANYTHING will default to CACHE_NONE because
that's what CACHE_ACCEL would do.
Possibly also T147161
Bug: T160519
Change-Id: I9ac2d071437b35a0f9cd3678e2279628f7b1931e
