Centralise management of all types of cron tasks with registration, scheduling,
parallel task conflicts(blocking) and running once off tasks, all using an
administration screen.
This is a combination of several issues:
MDL-25502: Added "black magic" task allocator for cron
MDL-25503: Add step to cron to run all scheduled tasks
MDL-25504 cron: Refactor to use scheduler
MDL-25505: Add an admin interface to schedule tasks via cron.
MDL-25507: Add support for adhoc tasks.
Suggested by Petr:
* Don't rely on single user for upgrade
* Make the pathnamehash generation a bit clearer (and add
a test to verify its correctly formed).
Kudos to Tim Hunt who came up with this, on mysql with 4 milion
records (and a fast SSD) the performance difference is:
Original: 36.83 sec
New query: 8.63 sec
* Upgrade function to remove duplicates from the grade item duplicates
column. Duplicates were causing sorting to fail in some cases.
* Add some unit tests which simulate sort order duplicate data and
verify that they have been removed.
This patch includes:
* version column removed from modules table, now using standard config, this allows decimal version for modules
* version column removed from block table, now using standard config, this allows decimal version for blocks
* module version.php can safely use $plugins instead of module
* new plugin_manager bulk caching, this should help with MUC performance when logged in as admin
* all missing plugins are now in plugin overview (previously only blocks and modules)
* simplified code and improved coding style
* reworked plugin_manager unit tests - now using real plugins instead of mocks
* unit tests now fail if any plugin does not contain proper version.php file
* allow uninstall of deleted filters
This prevents the upgraderunning lock from not being cleared when there are
no plugins to upgrade (reproducable bug with memcache as the application cache store)
This should resolve all problem on developer machines when switching branches or when restoring previous Moodle databases. It also prevents any potential problems during upgrades such as concurrent DB modification and resolves chicken egg problems in future caching upgrades.
Derek Woolhead tracked down the problem and what needed to be fixed. I
just made the patch.
The problem was that if $plugin->cron had changed in version.php, then
the version number in the database could end up wrong after the upgrade,
and so the upgrade would immediately run a second time.
