Олег Давидович: 1 версия импортирована

2024-10-21T08:51:01Z

1 версия импортирована

← Предыдущая версия	Версия от 08:51, 21 октября 2024
(нет различий)

1>Stronk7: New page: {{Template:Development:Backup 2.0}}{{Moodle_2.0}}NOTOC{{Work in progress}} == Non-functional requirements == * Change format dramatically, splitting current monolithic moodle.xml int...

2010-04-25T10:07:44Z

New page: {{Template:Development:Backup 2.0}}{{Moodle_2.0}}__NOTOC__{{Work in progress}} == Non-functional requirements == * Change format dramatically, splitting current monolithic moodle.xml int...

Новая страница

{{Template:Development:Backup 2.0}}{{Moodle_2.0}}__NOTOC__{{Work in progress}}

== 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 [[Development: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..

Development:Backup 2.0 overview - История изменений

Олег Давидович: 1 версия импортирована

1>Stronk7: New page: {{Template:Development:Backup 2.0}}{{Moodle_2.0}}__NOTOC__{{Work in progress}} == Non-functional requirements == * Change format dramatically, splitting current monolithic moodle.xml int...

1>Stronk7: New page: {{Template:Development:Backup 2.0}}{{Moodle_2.0}}NOTOC{{Work in progress}} == Non-functional requirements == * Change format dramatically, splitting current monolithic moodle.xml int...