backup/restore one topic only (not just one activity)? --Samuli Karevaara 07:35, 2 February 2009 (CST)
- Hi Samuli, feel free to add that to the Drop in ideas. Shouldn't be difficult if we have that in mind since the beginning. Thanks! --Eloy Lafuente (stronk7) 08:33, 2 March 2009 (CST)
Actually install.xml already contains most information that are needed to backup/restore component tables. If it will have some new features (mostly to describe id-links between a tables), it should be possible to make semi-automatic backup/restore in core, lifting from the modules a weight of backup code (which is really duplicates same pattern most of the way). The modules may still want some recoding capabilities on restored content if needed, but main backup/restore would be coded in core. Not very easy to implement, but quite an improvment to system architecture. --Oleg Sychev 19:21, 7 February 2009 (CST)
- Hi Oleg, absolutely! I've had that sort of "declarative backup and restore" in my mind since ages ago. I'm not sure if install.xml file will be the source for that sort of information or, perhaps, we could have one "parallel" structure, mainly because I'm sure we'll need to support some extra bits like custom functions and so on to be specified. In any case, install.xml can be the start for that, sure! --Eloy Lafuente (stronk7) 08:30, 2 March 2009 (CST)
I guess "parallel" structure, which will duplicate some info isn't a very good choice, as you'll (and module authors) would be tied up checking consistency of the data in two "parallel" structures. I think a new structure should either replace install.xml (so installer could get it's information from there), or it should take all information it can from install.xml, combining it with info from other sources. But I'd avoid duplication on such info. --Oleg Sychev 09:11, 2 March 2009 (CST)
- Hi again, I used the "parallel" adjective just to point that we cannot use current install.xml files at all as persistent definitions of backup and restore. And there are some good reasons for that:
- The whole XMLDB thing in Moodle is designed as one DB abstraction layer that can be "plugged" easily into other PHP projects. So it must continue being one "pure" DB layer, without dependencies with the rest of Moodle.
- install.xml files are "snapshots" of the database at a certain moment (when it's installed). Along the life of Moodle, those snapshots change, with new tables arriving, others being dropped (and same for fields). In the other side, backup & restore must support those changes along the life of Moodle, in order to keep upwards compatibility in backup an restore (so, for example, one 2.0 backup must be restored in 2.2 without problems). So, we must track all the changes in order to allow that to work, and obviously the install.xml files aren't the proper place to do so.
- These are the causes I think we shouldn't use the install.xml files as the place to store that backup info and the main reason to think we should have some sort of alternative backup.xml file. It's possible that, initially, a big part of those new backup.xml files can be written using install.xml files as source... but over the time... they will diverge, because the backup.xml will end having some extra info tracking all those changes and pointing about what to do with them. --Eloy Lafuente (stronk7) 11:58, 2 March 2009 (CST)
Ok, Eloy I see you point. But IMHO there is a better way to ensure upward compatibility: easier and more robust. Keeping track of all DB changes history is quite a bother, and there are only so much version it can span across. It will be much easier to make a copy of DB information directly in backup file, so restore engine could know it regardless of current versions.
The hard part is to restore old backup in case of serious db change (regardless of how it is stored, with backup.xml or directly in backup). Keeping track of changing isn't sufficient, there must be a procedure to do an actual upgrade of a data in non-trivial cases. Maybe the easiest accesible solution (if it should exist) is to restore info to temporary created tables and upgrade it using a function similar to the one in upgrade.php (or use it directly). --Oleg Sychev 16:56, 12 August 2009 (UTC)
Wizard UI design
Howdy Eloy - what changes are you planning for the UI of backup? I hope to get guidelines about the usage of wizards/assistants (notes) - which backup essentially is - into the MUIG, but I am not there yet. Would you give me a beep when it's the time for you to think about this? Thanks.--Olli Savolainen 08:46, 15 July 2009 (UTC)
Question bank backup
In Moodle 1.9 question backup is quite simple. Backuping any quiz results in backuping all questions in the course. This isn't very nice, because:
- often you need something particular in backup, not all tons of questions - it's relatively easy to backup only questions (or categories in the case of random questions) that are used in backuped activities (see MDL-12403)
- question categories now can be shared and belong not to the course, but to the course category for example and so on. There need to be some policy (and new controls probably) about backuping and especially restoring such questions. If I backup a quiz which use shared question and restore it in the new course in the same category should restore create new copy of the questions or links to a old ones?
- importing activities from other courses use backup/restore so importing quiz from a large course into small you'll get a whole load unnecessary questions
- sometimes you want just backup/restore some question categories without any activities at all; you can do import/export, but it is inconvenient and troublesome, because:
- each category should be exported (imported) separately;
- many 3d party question types does support backup/restore, but not import/export
This should be taken in consideration in Backup 2.0. I think question categories may appear on the backup screen along with activities (thought the should probably be automatically selected when appropriate quizzes selected). --Oleg Sychev 17:15, 25 August 2009 (UTC)
Backup entire Category with sub-Categories & Courses
Will Backup 2.0 allow the ability to backup an entire category & all of its sub-categories & courses? For example:
Top/Parent Category called: SEMESTER (SPRING2010) sub-Category called: PROGRAM1 courses in sub-category: Course1-1 Course1-2 Course1-3
sub-Category called: PROGRAM2 courses in sub-category: Course2-1 Course2-2 Course2-3
We would want the ability to define a backup job at the Top/Parent (SEMESTER) level which would include the subcategories and their courses. Then, at restore, we would want to define a new name for for the SEMESTER (such as SUMMER2010) & restore the sub-categories and their courses into that new parent. This process would act as a means to recreate course schedules en mass. We currently have over 400 courses in 5 sub-catagories under our Top/Parent (SEMESTER) category which have to be individually restored into the new SEMESTER category each term.