Affects Version/s: 2.6.2
Fix Version/s: 2.7
Open up a SCORM activity Delete any existing attempt Trigger a 'Commit' within the SCORM (this will depend on the specific SCORM) Check in the database that all expected scorm_scoes_track records have been created Trigger another 'Commit' within the SCORM Check in the database that any changed values have been updated in scorm_scoes_track, but that any unchanged values still have their original 'timemodified' values.
- Open up a SCORM activity
- Delete any existing attempt
- Trigger a 'Commit' within the SCORM (this will depend on the specific SCORM)
- Check in the database that all expected scorm_scoes_track records have been created
- Trigger another 'Commit' within the SCORM
- Check in the database that any changed values have been updated in scorm_scoes_track, but that any unchanged values still have their original 'timemodified' values.
Pull from Repository:
Pull Master Branch:
Pull Master Diff URL:
When 'Commit' is called in the SCORM API, the PHP function scorm_insert_track is called once for each tracking value that the SCORM has set.
This function calls:
- $DB->get_record() each time, to retrieve any current tracking record
- $DB->insert_record() or $DB->update_record() each time, whether or not value has changed.
This can be very slow for SCORMs that have a large number of values (one example I have sets about 10 values per question, for a quiz of 50 questions, so the number of values grows quite large by the end of the quiz).
I will submit a patch that:
- Preloads all existing tracking values for the current scorm + user + attempt
- Only updates the values if they have changed
The downside of this is that any 3rd-party report system that relied on the 'timemodified' field being updated for every tracking record, regardless of changes in value, would be broken (however, I suspect that such a report system would be inherently flawed anyway). The upside is that, from a quick local test, I've seen the processing time for 'Commit' go from 1200ms => 120ms. I would also argue that this is a more correct meaning of 'timemodified' in the first place (is the value really 'modified' if it hasn't been changed?)