Submission score details in *WS

[stefano-maggiolo]

Computing the score, the score type assigns some numerical value also to subtasks, testcases, or whatever it uses to obtain the score. The information on how the score got computed must be returned to the user, admins and the public (maybe with different flavors) as score details for each submission.

This issue is a place to discuss where we want to stand between the two opposites: let the score type build the table of score details with all the liberty it wants, or rigidly encoding the possible information that a score type can show to the users involved.

At IOI, the former approach was used, saving into the database a simple HTML table that was manipulated and stylized by the js, but apart being an ugly solution, it weighted down the database a lot, hence it is not a sustainable option for the future.

[giomasce]

My idea is an intermediate one: you need the ScoreType to be able to generate some HTML code that gets included in the CWS, but that code shouldn't be stored in the database. It should probably be generated on-the-fly when it's required, allowing the ScoreType to save a some private information in the database. This private information will be something like JSON are some other encoded string, but it isn't bound to any format: the only important thing is that ScoreType is able to use it to generate the HTML scoring details.

This mechanism, apart from prevent us from saving in the database things that shouldn't go there, also enhances flexibility, since it allows, for example, the scoring details to be localized.

[giomasce]

Sorry, inadvertently closed...

[stefano-maggiolo]

I have a proposed implementation for the issue (along the lines of Giovanni's idea), see the top three commits at https://github.com/stefano-maggiolo/cms/commits/master.

It uses JSON-encoded dictionaries to store the data, but in the interest of saving more bytes on the DB, we could change them to lists. I do not think it is really worthwhile, though. Maybe we can shorten the keys. Also, I added the marking for translations.

Please tell me what you think and if you have suggestions before merging.

[lw]

I put a couple of comments on the commit for really minor issues. Other than that I'm ok with this patch.

Just a note: making AWS load the score details for all submissions of a certain task when requesting the page for that task could be one of the reasons of the high load on the DB (even if we didn't use AWS that much at the IOI...). The same holds for user pages, even if the number of submissions there is lower.

[stefano-maggiolo]

I agree with the notes, I'll change them tonight. Definitely there were (there still are) a lot of reason for the relatively high load of the db...

[giomasce]

Il 26/11/2012 09:43, Luca Wehrstedt ha scritto:

Just a note: making AWS load the score details for all submissions of a certain task when requesting the page for that task could be one of the reasons of the high load on the DB (even if we didn't use AWS that much at the IOI...). The same holds for user pages, even if the number of submissions there is lower.

What do you mean with "load"? If you mean the transfer of such data from the DB to AWS, I'd say that it's mostly negligible. TTBOMK, SQL query's performances are usually measured in terms of number of pages that need to be fetched from the disc, which doesn't depend much on which fields are actually requested in the SELECT. I don't think that network transfer time is something that we really need to optimize that much.

Giovanni.

Giovanni Mascellani mascellani@poisson.phc.unipi.it Pisa, Italy

Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascellani@jabber.org / giovanni@elabor.homelinux.org

[lw]

Well, I know nothing about DBs so that was just a shot in the dark...

[stefano-maggiolo]

Pushed (temporary?) fix in cca0aca92cb80c447fd1b678464d5ce135fa435e.