Hello everyone,
Could you kindly tell me what is persistent grades feature exactly?
why is it disabled by default? and is it safe to enable it for a site with 20K learners or not?
is there any documents about it? (unfortunately I didn’t find anything by googling.)
thank you very much
1 Like
By default, grades in Open edX are computed on the fly and are not stored in the database. This can make it slow/expensive to do things like produce reports of grades for a large course. Enabling persistent grades causes the grades to be stored in the database (MySQL), which makes a lot of grade-related reporting much faster because the grades can simply be read out of the database instead of computed for each student/course/subsection.
I am also curious about why the persistent grades feature is still disabled by default and why the “non persistent” grades mode still exists at all. Would someone from edX be able to comment on that?
For what it’s worth, we have been using persistent grades for several of our Open edX installations of various size for several years without any issues that I’m aware of. I recommend enabling it if you’re using the Ironwood release of Open edX or newer (earlier releases are known to have some related bugs).
1 Like
+1 to that question - maybe @dave would know? If there are still issues with persistent grades, it would be good to have them in mind. Or if there is no reason to keep it off by default now, it might be worth switching the default for the upcoming Open edX release? CC @regis @nedbat
1 Like
I suspect it’s mostly because the transition was bumpy and we never got back to it after things had stabilized. My understanding is that it took weeks to backfill the grades for edx.org, and we had some early operational issues. Also, it’s worth noting that it is computationally expensive–about 2/3rds of the celery worker load for edx-platform on edx.org goes to asynchronous grade recalculation.
All that being said, it’s definitely worth it, it’s been stable since at least Ironwood, and I agree that it should be the default for Juniper. I’m not sure what’s involved with making that transition though (I wasn’t on the team that did that work). @iloveagent57 might know more about what’s required for a migration, but he’s on vacation this week.
Hi,
we found that in Ironwood or Juniper.master, when persistent grades are enabled and edx_sga xblock is graded, this makes lms.djangoapps.grades.tasks.recalculate_subsection_grade_v3 to throw a DatabaseNotReadyError() , and progress page is not updated…!
To reproduce it, enable persistent grades, add an edx_sga into a graded subsection, grade your assignment and go to progress page and check lms logs… Subsection grades are not updated. If you disable persistent grades, subsection grades calculated on the fly are ok.
Any thoughts?
2 Likes
A post was split to a new topic: Problems with sga grade submission
@dave Do you have any collection of potential issues with persistent grades? I looked for them, but found nothing.
Some days ago, we bumped into an issue related to persistent grades, and/or probably visual blocks. The issue may be caused by a race condition or similar, though we were not able to reproduce it since then.
The progress page resulted in an error when persistent grades flag was enabled. Enabling persistent grades flag seems to have broken the cache (or visual blocks?) somehow and resulted in a KeyError in models.py:
lms/djangoapps/grades/models.py", line 597, in read
prefetched_grades = get_cache(cls._CACHE_NAMESPACE)[cls._cache_key(course_id)]
Although this issue happened, did not affect all users just some of them.
Have you ever faced with similar issues?
1 Like
@gabor, Recently we enabled this feature on our Ironwood.master instance and we had a kind of Integrity Error. I wrote this patch to fix it. I haven’t rolled this back to see if the issue has gone or not.
2 Likes
Hello @mahyard,
Thank you for sending the patch! I’ll check it today if it is related to the issue we experienced. 
I wasn’t able to try it out yet, but I’ll follow up as soon as I have a result (latest on Monday). Thank you again for the patch.
As I promised, I’m getting back to here. I have no results yet, I’ll post the results as I have them.
2 Likes
Sorry if I bothered you,
but I think this depreciation should be mentioned along this thread.
Thanks @mahyard, this is a super interesting thread! I’ll try to answer some of these questions from my research.
1 Like
Hi @gabor, I ran into a similar issue when testing persistent grades cutover on my machine. It looks like an issue with an incomplete cutover to persisted grades for a user: e.g. a user tries to view the progress page after persistent grades are enabled, subsection grades are not found in the database, so it tries to fall back to the cached block data and tries to do a write (instead of update) causing a hash collision.
I believe this can be fixed by running the grades backfill job as detailed in this persistent grades cutover tutorial.
1 Like
Hello @nsprenkle, thank you for posting this!
Some days ago we applied the patch which resulted in no further issues. Although it may help to do the backfill in this case, we had no opportunity to try that out (the patch was deployed earlier than I saw this message).
Anyways, I’ll create a patch for Koa and master branches as well. 
1 Like
Thanks, @gabor! I’m hoping this would help with any cutover we’d have to do with moving to only persisted grades. Will put aside some time to review/test this and share the restults!