Backup 2.0 overview

Jump to: navigation, search
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..