Backup 2.0 overview

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
• 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..