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

Add a cache definition for grade categories

    XMLWordPrintable

Details

    • MOODLE_28_STABLE
    • MOODLE_31_STABLE
    • MDL-48838_master
    • Hide
      1. It SHOULD pass all behat tests
      2. It SHOULD pass all phpunit tests

      This is the real test:

      1. We are adding a cache for grade_categories (not the grade categories grade_items data). The grade categories data gets updated through the form, but for example, a gradebook recalculation shouldn't update grade categories data. In general we need to check that cache invalidation is working as expected, you can feel free to test what you want, but the basic test I think is required is to:
        1. Visit 'Site administration' > 'Grades' > 'Grade category settings' and enable all aggregation types.
        2. Go to a course grader report with at least 2 activities and one grade category using any 'Aggregation' method except for 'Natural'.
        3. Open the gradebook setup in a new tab and go to the grade category edit form, save without changing any value and return to the grader report, grades should be the same in the other tab.
        4. Now edit the category again and change the 'Maximum grade' value in the grade category form (remember the previous values, you will need to restore them) and check that the grader report grades change according to it, keep that tab opened with that data and open a new one going to gradebook setup again
        5. Restore the grade category previous values and go to the grader report to compare the grades with the initial tab, they should be the same
        6. Thank for testing this
      Show
      It SHOULD pass all behat tests It SHOULD pass all phpunit tests This is the real test: We are adding a cache for grade_categories (not the grade categories grade_items data). The grade categories data gets updated through the form, but for example, a gradebook recalculation shouldn't update grade categories data. In general we need to check that cache invalidation is working as expected, you can feel free to test what you want, but the basic test I think is required is to: Visit 'Site administration' > 'Grades' > 'Grade category settings' and enable all aggregation types. Go to a course grader report with at least 2 activities and one grade category using any 'Aggregation' method except for 'Natural'. Open the gradebook setup in a new tab and go to the grade category edit form, save without changing any value and return to the grader report, grades should be the same in the other tab. Now edit the category again and change the 'Maximum grade' value in the grade category form (remember the previous values, you will need to restore them) and check that the grader report grades change according to it, keep that tab opened with that data and open a new one going to gradebook setup again Restore the grade category previous values and go to the grader report to compare the grades with the initial tab, they should be the same Thank for testing this
    • 3.1 Sprint 5
    • Medium

    Description

      Login into the gradebook with different users, looking at different reports... there are always many repeated queries to grade_categories tables, they are simple database queries to grade_categories without any join with other tables, writes in grade_categories table are not specially high in comparison with the number of reads so it seems a good candidate to cache at application level as we will not invalidate the data often (similar to groupdata case).

      Same happens with grade_items, but I will create a separate issue for it.

      Attachments

        Issue Links

          Activity

            People

              dmonllao David Monllaó
              dmonllao David Monllaó
              Simey Lameze Simey Lameze
              Andrew Lyons Andrew Lyons
              Mark Nelson Mark Nelson
              Votes:
              7 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:
                23/May/16