MarkUs Blog

MarkUs Developers Blog About Their Project

Revised revised DB Schema for Remarks

with 7 comments

Edit: the final decision was to add 2 columns to the Sumbission table. “Remark_result_ID” which links to a remark result, and “remark_request” to keep the request in text form.

So, after a discussion during last Friday’s meeting, it seems that the best way to do this is to add a column to the Submission table and create a new Results object per remark. I think this then leads to adding two columns in the SubmissionFile table, to keep track of remark request files OR adding a blob column to keep remark requests.

Please see previous post for the previous blog discussion.

From what I understand of the discussion, the new schema suggested is as follows. There is a remark_results column added to the Submission table, which is the id of the new result object created for the remark.
0) Only 1 remark_result ID may exist for one submission (no multiple remarks)
1) If this column is NULL, then it means there is no remark requested.
2) If there is an id there, it means there is a remark requested.
3) If the remark result object’s marking state is “unmarked” it means that the request has still not been reviewed by the professor, and the student can still cancel his or her request. The original mark is still released to the student.
4) (If the student cancels, the result object will be removed and the remark_results column in the Submission table will be NULL again).
5) If the remark result object’s marking state is “partial” it means that the professor has started looking into the request. At this point, the student can no longer cancel the request. Both the original and remarked grade are unreleased to the student.
6) If the remark result object’s marking state is “complete” then both the original and remarked grades are released to the student.

The remark request would be saved in a text file on the server, and the file name and path saved in the SubmissionFile table under the columns “remark_filename” and “remark_path.” We could also standardize the filename so that we only need path. The other option is to save it directly into a “remark_request” column in the SubmissionFile table as a blob.

Quick question… Do we want to save when (timestamp) the remark request was made? I guess this could be saved in the remark text file.

Written by misa

November 8th, 2010 at 9:49 pm

Posted in Uncategorized

7 Responses to 'Revised revised DB Schema for Remarks'

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

  1. Misa:

    I’m on board with almost everything.

    I’m just not 100% on those remark_filename and remark_path columns.

    Why is the remark request being saved as a text file on the server? Up until this point, MarkUs has not saved a single thing in the file-system outside of version control. Why would we save this text-file, instead of saving the blob of text in the DB?

    In that case, a remark_request text field could be added to Submission.

    Or am I misunderstanding the situation?



    8 Nov 10 at 11:06 pm

  2. yep that was the other option (saving the request in a column). I saw the filename and filepath column for the submissionFile table, and assumed that submissions are saved onto the server or something. So I thought remark requests should too, if that’s the case. But I personally prefer blob option.


    8 Nov 10 at 11:44 pm

  3. Ok, gotcha. Yeah, blob option gets my vote.

    Just so you know what SubmissionFile does:

    When a Submission is collected, we look at all of the files within the repository for the appropriate revision, and for each file, create a SubmissionFile. A SubmissionFile is just the name/path of each file in the repository, and nothing else.

    A SubmissionFile is useful because it gives us something to attach Annotations to.


    9 Nov 10 at 2:34 am

  4. I vote for storing the request as a text blob too.

    “Do we want to save when (timestamp) the remark request was made? I guess this could be saved in the remark text file”

    Yes please. Knowing when a student made the request is important. I think the time I’d like is the time that the press submit.

    Karen Reid

    9 Nov 10 at 10:50 am

  5. In order to make changes to the DB, I was looking at schema.rb, but it says use Active Record in the migration feature.
    Do I create a file(class) in the DB>Migrate folder like:
    class AddRemarkResultToSubmission < ActiveRecord::Migration def self.up add_column :submission, :remark_result_id, : foreign_key :submission, :remark_result_id, :results end def self.down remove_column :submission, :remark_result_id end end I'd also need to do the same for the remark_requests column in the SubmissionFiles table, and also add rules to the results_id column in Results tag to delete?


    9 Nov 10 at 1:53 pm

  6. misa, use something like

    script/generate migration add_remark_result_to_submission

    to generate the file first, and then add the parts you need to the file.

    I think you would have a file for each different table you make changes to, although I could be wrong.


    9 Nov 10 at 8:42 pm

  7. aah sorry, I forgot to update my comment here. I already submitted the migration stuff for code review. Thanks though, Vivien!! =)


    9 Nov 10 at 9:45 pm

Leave a Reply