The Moodle import feature copies resources and activities (mods) from one to course to another. Unfortunately we found the import process rather unintuitive (although better in 2.3), and we wanted to improve its speed, reliability and ease of use.
We found that the Moodle import is based on the Moodle backup feature. Moodle backups create external representations of courses as a zip. It’s great at keeping packaged archives of Moodle courses, and sharing them. However, incorporating backup into the import process meant packaging mods into temporary zip archives and then unpackaging them again, even though all it really needs to do is copy a mod and associated files.
We found that relying on Moodle’s backup wasn’t the most efficient method. Our new import isn’t based on the Moodle backup functionality and as a result is faster, more robust and easier to use. Unlike the standard Moodle import tool it is also able to copy files linked from html within mods.
In this first of a trilogy of posts we’ll sketch out the database schema we are copying.
Database schema for generic course modules
The generic database schema for course mods looks like this:
Some of the Moodle mods have no further data associated with them than this. Others only have user generated data which the import doesn’t need to copy.
In our Moodle install mods with no further data associated with them include resources, assignments, chat modules, journals, forums, wikis and labels.
Some of the Moodle mods have subtables associated.
For example the choice mods have an associated table with choice options, the database mods have an associated table with database fields, and the feedback mods have an associated table with feedback items.
The lesson mods have an associated table with lesson pages and these pages have an associated table with lesson answers.
Database schema for glossary modules
The glossary was the only mod where we decided it was important to import user data as these included glossary definitions added by the tutors and a glossary without definitions wouldn’t be worth importing. As a result the database schema was a little more complicated. Glossary mods have associated tables with glossary entries and categories and there is a linking table between entries and categories. Furthermore, entries have an associated table with aliases.
Database schema for quiz modules
By far the most complicated mod was the quiz. The quiz has associated tables quiz feedback and quiz question instances. Quiz question instances joins questions from a Moodle question bank. The questions are in categories which are associated with the quiz itself through the context table.
There are number of questions types all using their own database schema. Most of the question types use the question answers table.
There are a number of question types which randomly pick questions. The random short answer matching (slickly named!) picks any short answer question in the category that is not currently in use to make a matching question by pairing the question and answers of the short answer questions. The random question will pick any question currently not in use in the quiz that is in the same category or a subcategory.
We hope this approach will be useful to others who have problems with import in moodle.
In the next posts we will talk about the unit testing we did to establish that import was working and finally the Sussex import feature in its working form.
As always, comments very welcome.