Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-44677

SCORM commit slow when there are a lot of unchanged values

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 2.6.2
    • Fix Version/s: 2.7
    • Component/s: SCORM
    • Testing Instructions:
      Hide
      • 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.
      Show
      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.
    • Affected Branches:
      MOODLE_26_STABLE
    • Fixed Branches:
      MOODLE_27_STABLE
    • Pull Master Branch:
      MDL-44677_scorm_commit

      Description

      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?)

        Attachments

          Activity

            People

            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Fix Release Date:
                12/May/14