Backup 2.0 known problems

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.

• Improve XML parsing: One of the major bottlenecks in backup and, especially, in restore reliability under Moodle 1.x has been the large amount of memory needed to handle those operations (see bugs like MDL-14302, MDL-15489, MDL-9838... and many others). While the whole XML file (moodle.xml) is parsed in a SAX way (hence, "streamed" and requiring small amounts of memory), we use to group some XML contents into "parts" in order to delegate the operations over those "parts" to different plugins (modules, blocks...). And problems arrive when some of those "parts" are big enough and processing them with the xml_parse_into_struct() function and the xmlize library uses exaggerated amounts of memory (for example, to process a 12.5MB file requires 311MB of memory, crazy!). So we need to switch to an alternate method to parse those "parts" using much less memory and to build the corresponding in-memory object with one acceptable throughput (speed).

• Upwards compatibility of Moodle 1.9.x backups: While the Backup 2.0 multiple formats document describes how different formats will be supported by the restore process in Moodle 2.0, it's going to be a highly complex task to perform the transformation of Moodle 1.9.x backups into the new, improved, Moodle 2.x backup format. Too many things have changed between both versions to be able to achieve this easily. Surely it's computable (as long as upgrade is being able to apply the correct logic, so restore will) but it is going to be handled as a separate development that will allow us to 1) be centred in the 2.0 backup/restore and 2) be free (both in mind and implementation) from any 1.9.x XML format dependency.