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

Invalidate the backup_ids cache on backup_ids_temp table recreation

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.3
    • Fix Version/s: 2.3
    • Component/s: Backup
    • Labels:
      None
    • Testing Instructions:
      Hide

      0) This requires one NEW site, without existing users, OR alternatively, verify that none of these usernames exist in the site (admin1, student, teacher). Else, the results of the execution of the restore can be "lies".

      A) Run phpunit tests
      B) Test: No failure happens in test_backup_ids_cached().
      C) Restore the course http://tracker.moodle.org/secure/attachment/28420/backup-moodle2-course-itc1-20120531-2114-modified.mbz
      D) Test: Ends without error (ignore notices about mappings). 2 users are shown as participants ("sam student" and "teacher tom")

      Show
      0) This requires one NEW site, without existing users, OR alternatively, verify that none of these usernames exist in the site (admin1, student, teacher). Else, the results of the execution of the restore can be "lies". A) Run phpunit tests B) Test: No failure happens in test_backup_ids_cached(). C) Restore the course http://tracker.moodle.org/secure/attachment/28420/backup-moodle2-course-itc1-20120531-2114-modified.mbz D) Test: Ends without error (ignore notices about mappings). 2 users are shown as participants ("sam student" and "teacher tom")
    • Affected Branches:
      MOODLE_23_STABLE
    • Fixed Branches:
      MOODLE_23_STABLE
    • Pull from Repository:
    • Pull Master Branch:

      Description

      This was discovered as part of the research performed for MDL-33455.

      Along the whole restore process we need to ensure that any destructive operation performed to the backup_ids_cache table (deletion of records, complete truncate, drop & recreate) leads to the invalidation of the in-memory backup_ids caches.

      Luckily, the only destructive operation is that, in the middle of the process, once the restore prechecks have ended, the backup_ids_temp table may be dropped and recreated (optionally, depending of the results of the prechecks and the type of execution).

      So we need to guarantee that, each time the backup_ids table is created, any existing cache referring to it is invalidated.

      Results can be really disastrous if this isn't kept on sync. In fact they are (no user created at all, possible messing of parents information...).

      So this is about to:

      1) create one reset_backup_ids_cache() method that will invalidate the caches.
      2) execute it each time the backup_ids_temp table is created.

      Ciao

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                stronk7 Eloy Lafuente (stronk7)
                Reporter:
                stronk7 Eloy Lafuente (stronk7)
                Integrator:
                Sam Hemelryk
                Tester:
                Sam Hemelryk
                Participants:
                Component watchers:
                Adrian Greeve, Mihail Geshoski, Peter Dias
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Fix Release Date:
                  25/Jun/12