This is the preferred method as it enforces read-only mode for DB_REPLICA
and handles LoadBalancer::reuseConnection() calls automatically.
Change-Id: Iab9439ba8e0810fa14c302661ed7a3534f6bfc0d
Storing the user name or IP in every row in large tables like revision
and logging takes up space and makes operations on these tables slower.
This patch begins the process of moving those into one "actor" table
which other tables can reference with a single integer field.
A subsequent patch will remove the old columns.
Bug: T167246
Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50
Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
This pattern is already used elsewhere and seems like a more efficient
way to acquire locks in a non-blocking way.
Change-Id: Idb369e7cb03b793d5f8295e956fecd8d1f849e17
* Mark method visibility
* Remove unused code/methods
* Use WAN cache process cache in pagesInNs()
* Remove "m" prefix from SiteStatsInit fields
* Avoid use of $wg variables
Change-Id: Iab4001f02c9b2e8667ca4bac033fd4f6ef272148
We already exclude external (mostly Wikidata) actions from counting on
Special:ActiveUsers as of 56524c05. Should be consistent.
Change-Id: Ib69a614a65246a0f4f47365751f9bef130f47475
This is more consistent with LoadBalancer, modern, and inclusive
of master/master mysql, NDB cluster, and MariaDB galera cluster.
The old constant is an alias now.
Change-Id: I0b37299ecb439cc446ffbe8c341365d1eef45849
This fixes a phpunit test error, wherein {{NUMBEROFFILES}} would give
the number of files in the host wiki, not in the temporary database,
when Scribunto was installed, due to a Scribunto phpunit data provider
calling SiteStats::pages().
Change-Id: Ic0d021a72addaa2a13a6b94fd34dccc423de3a8f
In addition to updating the database / memcached, make SiteStatsUpdate also
update the context stats object with the deltas it is processing.
Change-Id: Icc12c07ab4233e1105a402b80d290bdb64df6ea7
The grouping makes at least as much sense as job/, and certainly makes
more sense than cache/. With directories named after base classes, it is
fairly easy to tell what should go where. The grouping of
DeferredUpdates, DataUpdate and CallableUpdate would surely be
uncontroversial.
The move of SearchUpdate out of search/ demonstrates the conflict between
arrangement by module versus arrangement by type, which is the most
difficult design question here. I think arrangement by type is more
consistent with e.g. the arrangement of the core root, i.e. tests/,
resources/, maintenance/, etc. where a given feature will have its files
split up into a mostly type-based hierarchy.
I also tidied up AutoLoader.php by moving includes/content to the correct
location, sorted alphabetically by subdirectory.
Verified with AutoLoaderTest.
Change-Id: Ib369411d0caca38e72978084aa57348f1b892ed0
