* Follow-up 25a44aa3e4
* The static DataUpdate::enqueueUpdates() method will
deal with JobQueueGroup construction instead
Change-Id: Id7741a770cee81fdc3f61804b7574ccf737bc338
* Updates can now declare themselves as having enqueueUpdate()
as an alternative to doUpdate(). This lets more expensive
or slave lag producing updates use the job queue if desired.
* Added a $mode flag to DataUpdate::runUpdates() to prefer
pushing jobs over calling doUpdate().
* Made page deletions defer deletion updates when possible.
Bug: T95501
Change-Id: Ic6f50f92768089ba0fbc223b8d178f5a91512959
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I7b65fe04db431342cc58b469dc48f41a50c4e891
Also removed true as second parameter to it from CloneDatabase.php
since it is the default value of that parameter.
Change-Id: I727ebae2bd4df0e26019985ce8c7ce73381c5642
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
