PrairieLearn
PrairieLearn copied to clipboard
Question list page, add last modified column
@ffund asked in office hours today about adding a "last modified" column to the instruction question view to allow sorting based on recent activity
I was just about to come and make an issue about this! This would be so useful for me this summer while I've got half a dozen students creating questions for my courses.
Hey! I'd be happy to pick this one up; just to confirm, the idea is to add a sortable "Last Modified" column on this page right?
i.e., the "https://ca.prairielearn.com/pl/course/9/course_admin/questions" tab
@michaelfromyeg that's what I had in mind, yes.
Thanks @michaelfromyeg !
The one question to think about is "which file" needs to be edited to show up in that page.
Options are:
-
info.json
file -
question.html
file -
server.py
file - Any file
I think "any file" is probably best, but I wanted to just ask what your plans were.
I also think it should be "any file" in the question directory (not limited to those three either).
Just taking a look at this, and while checking the files in a local dev environment makes sense, this would probably be harder to measure in a production server that uses chunks and caching to store question data. I believe in that case it may be better to use git log
to determine the last commit that updated any file within the question's directory if there is a repository, falling back to the stat of the containing files if there is no repository.
Adding to that: I think this has the potential of being a somewhat expensive operation, given the requirements to either make lstats or git log operations for all questions, and particularly considering this will likely be a column that will not be used by default. This probably requires a bit further thought process with how and when this value is computed.
Yeah, disk IO is expensive and should not be in the rendering path of the question page. The right way to do this would be to store it in the DB and recompute it every time a sync is performed. Syncs already do a lot of file IO and Git operations, so it's ok to add some more. This also has the advantage that syncs are guaranteed to take place within the context of a Git repo (at least in production environments), which makes it relatively easy to reliably determine last modified dates.
The right way to do this would be to store it in the DB and recompute it every time a sync is performed. Syncs already do a lot of file IO and Git operations, so it's ok to add some more. This also has the advantage that syncs are guaranteed to take place within the context of a Git repo (at least in production environments), which makes it relatively easy to reliably determine last modified dates.
The disadvantage of this approach would be that it might make it harder to reliably identify the modification date in non-Git environments (e.g., local development). Not sure how much of an issue that is, though considering instructors that create their assessments locally this may need to be taken into account.