Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Talk:Backup 2.0

From MoodleDocs
Revision as of 08:46, 15 July 2009 by Olli Savolainen (talk | contribs) (→‎Wizard UI design: new section)

Restoring sections

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)

Semi-automatic backup

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:
  1. 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.
  2. 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)

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 (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)