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!

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!

Making Moodle’s forms less intimidating.

Forms in Moodle have always been a bit lacklustre. Whenever I am training staff on how to use them I have to admit that the forms “look scary but are mostly irrelevant” when adding new modules or editing course settings. Gladly this is all set to change with the upgrade to Moodle 2.5.

For those of you who haven’t looked into this too closely I should explain that Moodle uses a class called MForm to make it really easy to build forms in Moodle. These forms are then rendered in a pretty standardised way. In Moodle 2.5 these forms have been streamlined to hide the superfluous settings within an expandable tab by default

I had been looking at the possibility of writing a YUI module to take these mform pages and give them a tabbed format which highlights sections with required fields. But with these improvements it may be possible to do this with just CSS.

I will keep posting about my progress, but it occurs that there are a few difficulties which I am going to have to think about fairly carefully:

  1. MForms are not used everywhere that you would expect. For example when editing the settings on the front page of Moodle I was suprised to find that it presents itself without any fieldsets and without the standard mform classes.
  2. MForms are used where you wouldn’t expect. Right the way through the course import process the pages are dynamic mforms in two columns making the styling look slightly out of place.
  3. Not all required fields are required. By which I mean that you can create a completely useless instance of the “File” resource, but really we want the attached file to be highlighted to the user as a priority. Somehow this has been overcome in the new version of Moodle, but I’m not sure how dependable that is.

Hopefully I will be able to come up with a non-invasive solution for tabbed forms in Moodle!