Delegated Transactions with $DB

For the last couple of days I have been working on a new plugin called “MIS Enrolment” which allows you to connect to records on an external database and then enrol users onto a Moodle course based upon their participation within that programme. The enrolment method works by allowing teachers to create an abstract “link” between their course on Moodle and their programmes held by MIS.

Enrol MIS Instance
Teacher’s admin panel for linking their Moodle courses to MIS “programmes”

This creates a many to many relationship between Moodle courses and MIS programmes and will allow teachers to easily enrol both staff and students onto the correct courses based upon the records held by an organisation’s MIS. More information to come on this over the next few weeks!

For now I am revisiting an old problem which I originally dealt with in my first month of developing for Moodle 2. In order to get this enrolment method working effectively we have to create and maintain an internal copy of the data from MIS. Normally you could just truncate (wipe clean) your records and insert them again from source, but in this case I need to compare and check:

  • What records already exist? Do they need updating?
  • What records are new? They will need inserting!
  • What records are missing from MIS? They will need archiving!

And when you are looping through 10,000 records or more this can all result in a great many individual inserts, selects and deletions. So how can you maximise the efficiency of all this? This time round I am making use of delegated transactions in Moodle to handle the bulk of database inserts.

The mechanism effectively defers all the transactions with a database to one large transaction at the end of a process. As a result you can save lots of memory and significantly reduce execution time because your script isn’t constantly waiting on the database to return some data.

For comparison I tried inserting my test participation data of 9483 new records. Using the standard DB functions the script took 47 seconds to execute, working at a steady 202 transactions per second. By comparison the delegated transaction took just 10 seconds to handle exactly the same data inserts, an effective rate of 948 inserts per second.

If you are working with large datasets on Moodle I would definitely suggest checking this functionality out as part of your project!

AutoEnrol 1.2 now stable

After a couple of months in testing AutoEnrol 1.2 has now been given a stable release at Moodle.org. There are a fair few additional settings to get your teeth into now, but the module works pretty much the same at it’s heart and can be updated from any previous version.

You can download the new version from either of the links below

Moodle.org

MoodleMark.com

I’m still keen to hear feedback on this release so if anyone has any feedback for how the plugin could be improved please do drop a reply to this post or send me an email.

Backwards compatible collapsible forms

If you are lucky enough to be running Moodle 2.5 the chances are you will have encountered the wonderful new collapsible forms. I’m really excited to get these onto our production server as they remove the user fear factor which can result from displaying a form with too many options

Collapsible Form Sections

If you are coding a new Moodle form and you want to take advantage of this, the sections can be collapsed or expanded like this:

$mform->addElement('header', 'generalsection', 'General Header');
//expanded
$mform->setExpanded('generalsection');
//collapsed
$mform->setExpanded('generalsection', false);

Great! But what about if you want this form to work with Moodle 2.4 or earlier? The best solution to this is just to check that the setExpanded method exists within the mform class, and then to wrap your code with an if statement.

$mform->addElement('header', 'generalsection', 'General Header');
if(method_exists($mform, 'setExpanded')){
        $mform->setExpanded('generalsection');
}

Hope that helps someone out there!