Backup 2.0 overview
From MoodleDocs
Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable. |
Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable. |
Non-functional requirements
- Change format dramatically, splitting current monolithic moodle.xml into smaller pieces (1xplugin, 1xusers, 1xroles, 1x...). Working in experimental way since 1.9, proved to be great for speed (saves ~20 repeated parsings of the whole file). No dependencies from previous stuff at all.
- Change the current "xmlize" approach when restoring files to one new progressive_parser instead. Each part of restore will decide how it wants to receive the information and who is in charge of processing it. Great for memory.
- Allow 1-activity, 1-section and 1-course backup. Use different shells/envelopes for any type of backup, keeping the "content" the same.
- Unify all multiple backup variations (course backup, course export, silent backup, scheduled backup) into a single codebase. Same for multiple restore.
- Backup and restore execution function (only ONE function, the executor!!) will be "blind": They won't perform decisions based on (changing) roles/capabilities/configuration settings any more. One master "backup_director" object will direct them once the object has performed all validations and ensured the process is executable. That director will handle/decide/instruct the executor about output/logging and everything else.
- Store complete information about any backup/restore performed in the site. This will include all the information for the the director (array-serialised) and the results of the executor. And obviously all the logged info cached when running.
- Important UI changes:
- UI won't make any processes! (like pre-calculating, or post-checks and friends). It will be completely separate from the "director" and the "executor".
- Complete site/user defaults
- View the backup/restore form in "course" organisation (inline? nah for 2.0 IMO) instead of grouped by activity mode. Surely over multiple configuration "steps".
- Bunch of new detail-options (restore section descriptions, overwrite course settings..., usually requested).
- Reuse code like crazy. Some things like the "id-remapping" on restore, the logs output, the "flush" output and so on will be central and any point of restore will be able to request that "services" or "utilities" when desired in a easy way (mini PHP-API to define things in a declarative way VS one/multiple helpful backup/restore "utilities" classes).
Preliminary notes
Splitting information
- All the existing/required caps define behaviour for each one.
- All the zones and splitter.
- Files backup/ restore.
- 1.9 => 2.0 transformations.
- Shells, separate structure and activities/blocks.
- Backup by "context". Each "context"(or inner items) will have:
- users
- groups
- files
- logs
- blocks
- role definitions
- role assignments
- role overrides
- completion info
- conditional info
- comments
- tags
- questions and categories
- gradebook: scales/outcomes and "activity grade items".
- gradebook: agregations/calculations and categories.
- filters
- metadata
- messages
- events
- blogs
(alternatively, all these parts can be found at the end of the backup file, globally for all contexts)
CZ Hackfest thoughts
- Need stamps for users (perhaps not because of MDL-16658) and roles (like question/categories ones) to guarantee uniqueness.
- Need to decide about backup file names (moving from .zip to .xxx). Multiple extensions or prefixed info to "tell more" about the backup type.
- 1.9 => 2.0 restore:
- Really complex, needs to mimic all current logic in upgrade.php scripts:
- xml transformations --> relatively easy
- files migration (course and moddata)
- wiki, resources, workshop transformations (complex)
- incoming question bank changes.
- surely other stuff (comments, messages, blogs)
- Possible solutions:
- How:
- Reuse as much as possible code from upgrade scripts. Not everything is re-usable (bulk changes).
- Re-implement all the logic in restore.
- Forgetting about it
- When:
- In one step, so Moodle 2.0 will natively-on-the-fly be able to process 1.9 files. Impossible!
- Keep it within Moodle, so conversion will be executed transparently immediately before restore (in the original plan at Backup 2.0 multiple formats.
- Completely separate utility, so files need to be transformed before being accepted by restore.
- Never
- Where:
- Restore everything into some duplicate tables in order to do the conversion there.
- Do that into memory/some specialised tables not duplicating anything.
- Nowhere
- How:
- Really complex, needs to mimic all current logic in upgrade.php scripts:
- Scheduled backups (it's just a "timed" backup iterator). Do we want it to continue being part of Moodle or have a separate utility. Using moodle cron or its own one?
- Incremental backup/restore. Is also a external thing. We provide constant "content" by separating envelopes and content, but all the "diff", "patch" stuff is no related with Moodle at all.
- Structures over course level. They are a pain. Can lead to non-restorable courses or differently-behaviour courses.
- ... more ideas/things..