This part of the code is changing an index on the course_sections table to be unique, for this to happen in the upgrade script the index must be deleted and then the new version added.
Before this change the following was being done:
* The index is removed
* A query to delete records that were not unique on this index is performed
* The unique version of the index is added
After this change the following happens:
* A query to delete records that were not unique on this index is performed
* The index is removed
* The unique version of the index is added
When the original index is present the query uses it, which greatly improves the execution plan.
Before the change an upgrade on a site with around 387967 course_section records the upgrade would be stuck on the delete query for many hours, after the change the time can be measured in minutes.
It is important to be able to tell which behaviours are in use, and
without this index, it requires a complete scan of this table, which can
be very big, to verify that a behaviour is unused.
Converts existing data to new structure in database as part of
upgrade, including a progress bar.
Deletes the database tables and fields that were used by the old
system and are no longer needed.
In previous (merge) commit, version was moved, on conflict
to 04 (coz 01) was already in use. This commit moves the 3
upgrade steps to 02, 03 and 04, matching that final version.
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.
This data should all have been upgraded when moving to Moodle 2.1. It
was only kept as a back-up, and now, after 3 years have past, we can
clean it up.
This locking system is designed to be used everywhere requiring
locking in Moodle. Each use of the locking system can be configured
to use a different type of locking (or the same type with a different
configuration).
The first supported lock types are memcache, memcached, file (flock),
db (specific handlers for pg, mysql and mariadb).
Frederic Massart