MarkUs Blog

MarkUs Developers Blog About Their Project

Revised DB Schema for Remarks

with 7 comments

Edit: Please see updated post here

In my previous post, I had mixed up Results/Marks with GradeEntryForms/Grades. Since assignments are linked to Results/Marks, that’s the one we should be changing.

To the existing schema, I added a “RemarkExtraMarks” and “RemarkMarks” table (identical to the ExtraMarks and Marks tables). The “Results” table now has 2 more boolean columns “remark_requested” and “remark_begun.” Let me explain the addition of the 2 boolean columns.

Initially, I had only planned on adding one boolean column “remark_requested” to keep track of whether there are remarks or not. However, with this schema, we run into the problem of the system not being able to distinguish between original marks being completed and released and remark requested but not processed, versus remark being completed and released. We want students to be able to see their marks until the professor has actually started looking into the remark, so the original marks need to stay ‘completed and released’ until then.

Then, I also considered adding remark states to the existing “marking_states” column, but this would create a lot of UI complications (and a lot of bug potential!). We also wanted to avoid making a “remarking_states” column because it would create redundancy.

After discussing with Mike, we decided on adding 2 boolean columns – “remark_requested” and “remark_begun.” Let me walk through the scenarios:
1) Student has put in a remark request. At this point, “remark_requested” = true and “remark_begun” = false. Original grades are still completed and released to the student.
2) Professor starts to look into the remark. This unreleases the mark to the student, marking state changes to pending, and “remark_begun” = true.
3) Professor finishes the remark, re-releases mark, marking state changes back to complete, and “remark_begun” is still true. (“remark_begun” is still true because this helps us distinguish between stage 1 and stage 3)

1b) If a student decides to cancel his/her remark request (which he/she can only do before the professor starts stage 2) “remark_requested” = false, and nothing else changes.

Thank you Mike for helping me out with the schema!!

Written by misa

November 3rd, 2010 at 3:57 pm

Posted in Uncategorized

7 Responses to 'Revised DB Schema for Remarks'

Subscribe to comments with RSS or TrackBack to 'Revised DB Schema for Remarks'.

  1. Rails is big on the DRY (Don’t Repeat Yourself) principle. Is it really necessary to duplicate the RemarkExtraMarks and RemarkMarks tables? Why not just add a type or kind field on the ExtraMark and Mark models, which would specify whether it’s a remark or an original marking?


    3 Nov 10 at 5:20 pm

  2. I agree with Tara – I imagine RemarkExtraMarks and RemarkMarks would carry the same information as ExtraMarks and Marks.

    Now that I think about this some more, maybe we should move the remark_requested and remark_begun fields to the Submissions table instead.

    Then maybe a Submission has_one RemarkResult (which subclasses from Result). Then, Marks and ExtraMarks can be applied to the RemarkResult.

    Just an idea.

    Mike Conley

    3 Nov 10 at 5:24 pm

  3. I’m wondering what some of the UI complications are as a result of adding remarking states?

    Mike – what happens if a student requests more than one remark?

    Is it possible to just replace the Marks and ExtraMarks with the new marks from remarking and then store the old marks and data in some other way? Then we could extend it to save old marks in general. I recall Karen mentioning that it could just be saved to a file. I’m not sure if this will be better than storing it as suggested above though since it would be nice to be able to retrieve the old marks quickly from the db.


    3 Nov 10 at 11:18 pm

  4. It sounds like the process flows through a series of distinct states – submitted, marked, remark requested, remark in progress, remark complete.

    Rather than model these as separate boolean flags (which now need to be checked for consistency), I suggest using a single column containing a string representing the current state.

    I agree with Vivien’s last point – unless it’s a common case to need to look up previous values for the mark, the rest of the code is likely to be simpler if you only store one mark and have a separate history or audit trail if you need to find the pre-remark information.

    Irving Reid

    4 Nov 10 at 9:36 am

  5. I like Irving’s suggestion with respect to states. Sounds cleaner to me.


    4 Nov 10 at 8:03 pm

  6. Vivien:

    Hm – I was operating under the assumption that a student could only request 1 remark. Misa told me that this was the requirement, anyhow.

    So this single column for holding state – something like remarking_state, holding values like “no remark requested”, “remark pending”, “remark complete”?

    I’m fine with that. I really wouldn’t want to add states to marking_state though – I think that’d add a bit of complication to the grader UI.



    5 Nov 10 at 11:10 am

  7. I don’t think it is necessary to version marks. I’m happy to keep one set of “original marks” and one “revised marks”.

    We don’t normally allow a student to request more than one remark per assignment, but I might make more than one modification to marks on an assignment.

    I also agree with Vivien’s last point. The revised marks become the official marks. The “original marks” are kept just to remind the person doing the remarking of what the original state was.

    Karen Reid

    5 Nov 10 at 12:12 pm

Leave a Reply